─ Integrated Business Planning 完全理解ガイド ─
2026年6月
「SAP IBP」という言葉を耳にしたことがある方は多いでしょう。しかし、その本質を正確に理解している方は、まだ多くはないのが現実です。「ERPの一部なのか」「需要予測のツールなのか」「Supply Chain Plannerが使うものなのか」──このような断片的な理解のまま、IBP導入プロジェクトに臨むことは、非常に危険です。
本稿の目的は、SAP IBP（Integrated Business Planning for Supply Chain）の全体像を、技術仕様ではなく「経営の言語」で解説することにあります。ERPの刷新やサプライチェーン改革を検討している事業会社のITリーダー、ならびにプロジェクトを支援するコンサルタントが、IBPを「投資判断の言語」と「実装の設計思想」の両面から理解できるよう、構成しました。
本稿を読み終えたとき、「IBPとは何か」「なぜS/4HANAと一緒に導入されることが多いのか」「どのモジュールから着手すべきか」という問いに、自信を持って答えられるようになることを目指しています。
SAP IBP（SAP Integrated Business Planning for Supply Chain）とは、企業のサプライチェーン計画機能全体を、単一のデータモデル上で統合管理するためのクラウド型プランニング・ソリューションです。簡潔に言えば、「需要・供給・在庫・財務の計画を、ひとつのプラットフォームで同時に、リアルタイムに扱う仕組み」と理解してください。
IBPという概念は、もともとSAP独自の造語ではありません。S&OP（Sales and Operations Planning：販売事業計画）というビジネスプロセスが、財務計画・サプライチェーン全体に拡張・進化したものが「Integrated Business Planning」と呼ばれるようになりました。そしてSAPが、このプロセスを支えるソリューションとして提供するのが、SAP IBPというソフトウェア製品です。
IBPを理解する上で最も重要な概念は「統合（Integrated）」という言葉です。従来の多くの企業では、需要計画・供給計画・在庫計画・財務計画がそれぞれ異なるシステムやExcelスプレッドシートで管理され、各部門が「自分のデータ」を持って動いていました。この「計画の分断」こそが、過剰在庫・欠品・需給ギャップといった慢性的な経営課題の根本原因となってきました。
IBPはその構造的な問題を解消するために設計されています。単一のデータモデルを基盤に、全部門の計画プロセスを接続することで、「ある変数が変化したとき、サプライチェーン全体にどのような影響が生じるか」をリアルタイムで把握し、最適な意思決定を可能にします。これがIBPの本質です。
IBPの前身であるS&OP（販売事業計画）は、もともと需要と供給のバランスを取るためのプロセスとして発展してきました。SAPの公式資料によれば、S&OPの成熟度モデルは以下の6段階で定義されています。
実行可能計画の登録
需要と供給の調整
最も収益性の高い応答の促進
需要主導型サプライチェーン機能の構築
市場主導型バリューネットワークを介した調整
在庫の最適化
IBPは、この6段階すべてに対応するソリューションとして設計されています。S&OPが「需要と供給を調整する社内プロセス」に留まっていたのに対し、IBPは財務計画との統合、戦略的計画から業務実行へのリンク、さらには市場や顧客との外部連携まで視野に入れた「経営全体の統合計画基盤」へと進化しています。
この進化を理解することが、IBPを「単なるプランニングツール」と見なすのではなく、「経営変革の基盤」として位置づけるための出発点となります。
現在、多くの企業がグローバルレベルで事業を展開しており、市場のボラティリティと競争の激しさは増す一方です。SAP IBPのコンセプト資料が端的に述べているように、「企業の競争上の優位性は、変化の激しい市場状況に迅速かつ正確に対応する能力によって決まる」時代となっています。
この環境下で、従来の計画プロセスは構造的な限界を露呈しています。典型的な課題は以下のとおりです。
需要予測の精度低下：市場の不確実性が高まる中、過去データに依存した統計予測だけでは対応できないケースが急増しています。プロモーションや外部イベントの影響、顧客需要のリアルタイム変動に対して、月次サイクルの計画プロセスでは反応速度が追いつきません。
計画の「縦割り」問題：販売部門は強気の需要予測を立て、サプライチェーン部門はそれを独自に調整し、財務部門はまた別の数字で予算を管理する。この「三つの数字が走る」状態は、組織の意思決定を麻痺させます。
可視性の欠如：在庫がサプライチェーンのどこにあり、いつ顧客に届くのかがリアルタイムで把握できないため、判断が常に後手に回ります。
過剰在庫と欠品の同時発生：適切な需給計画がないため、あるアイテムは過剰在庫を抱えながら、別のアイテムでは欠品が発生するという、経営的に最も避けるべき状態が恒常化します。
IBPが解決しようとする最大の問題は「計画の分断」です。多くの企業において、需要計画・供給計画・在庫計画・財務計画は、それぞれ異なるシステム・ツールで管理されており、その連携は月次の会議体と手作業によるデータ転記に依存しています。
この状態が経営にもたらすコストは甚大です。需要予測の誤りが供給計画に反映されるまでに数週間のタイムラグが生じる。供給制約の情報が販売計画に届かないため、「売れるのに売れない」という機会損失が発生する。在庫の最適化が各部門の個別判断に委ねられているため、ネットワーク全体での最適解が得られない。これらはいずれも、計画プロセスの「統合の失敗」から生じる損失に他なりません。
IBPは、このような構造的な問題に対して、単一のデータモデルと統合されたプランニング・プロセスという解答を提示します。「データを一か所に集め、人をつなぎ、シナリオを比較する」というIBPの基本思想は、まさにこの問題を直接的に解決するために設計されています。
SAP IBP for Supply Chainは、複数のモジュールから構成されており、企業は自社のビジネス優先事項に応じて導入するモジュールを選択し、段階的に拡張していくことができます。主要なモジュールは以下のとおりです。
販売事業向け SAP IBP（IBP for S&OP）：需給調整の司令塔機能
需要向け SAP IBP（IBP for Demand）：統計的需要予測とデマンドセンシング
在庫向け SAP IBP（IBP for Inventory）：科学的な安全在庫・目標在庫の最適化
応答および供給向け SAP IBP（IBP for Response and Supply）：実行可能な供給計画の生成
これらのモジュールは、すべて同一のプラットフォーム・データモデル上に構築されています。この点が最大の差別化要因です。異なるベンダーのシステムを統合する場合に不可避なインターフェース開発が不要であり、すべてのモジュールが共通のマスターデータとキー数値を参照するため、計画の整合性が自動的に保たれます。
IBPの展開において、一般的に最初に選択されるモジュールは「販売事業向けIBP（S&OP）」です。需要と供給を同期させることが困難な場合、まずこのモジュールから着手することで、その後に続く他のモジュールの展開を大幅に加速できます。
一方、適切なタイミングで適切な場所に適切な在庫を確保することに課題がある場合は「在庫向けIBP」から、複雑な供給ネットワーク全体の計画に課題がある場合は「応答および供給向けIBP」から着手するケースもあります。重要なのは、「ビジネスの優先事項に基づいてデプロイする」という原則です。
すべてのモジュールは同じプラットフォームで提供されているため、段階的に展開を拡張する際も、高価な統合開発は不要です。これがIBPの展開戦略における最大の利点と言えるでしょう。
IBPにおけるS&OP（Sales and Operations Planning：販売事業計画）は、サプライチェーン全体にわたって需要と供給を調整し、ビジネスの成果を促進するための中核プロセスです。IBPのS&OPモジュールは、複数の計画レビュー・サイクルを通じて、組織内の各部門（販売・マーケティング・サプライチェーン・財務・経営陣）が一つのコンセンサスに向かって収束することを支援します。
具体的には、以下のレビューサイクルが標準プロセスとして提供されています。
需要レビュー（Demand Review）：統計的需要予測と販売・マーケティングの判断を統合し、コンセンサス需要計画を確定する
供給レビュー（Supply Review）：需要計画に対して、生産・調達・物流の供給能力を照合し、制約と余力を可視化する
照合レビュー（Reconciliation Review）：需要と供給のギャップを特定し、トレードオフの意思決定を行う
管理ビジネスレビュー（Management Business Review）：経営陣が最終承認を行い、計画を実行へ移す
このプロセスは、各部門が「自分の計画」をバラバラに持つのではなく、「一枚の計画」に向かって協業するための仕組みです。IBPのS&OPモジュールは、このプロセスをデジタルで支援し、各レビューの進捗管理・タスク管理・シナリオ比較を可能にします。
IBPのS&OPプロセスにおけるデータの流れを理解するために、「コンセンサス需要（Consensus Demand）」という概念を押さえることが重要です。コンセンサス需要とは、統計的需要予測・販売チームの判断・マーケティングチームの見込みを統合した、組織全体として合意した需要計画の最終値です。
IBPでは、複数の需要関連キー数値（販売予測数量・マーケティング予測数量・統計的需要予測数量など）を同一の計画ビュー上で比較・調整することができます。最終的に確定したコンセンサス需要が、供給計画の入力として機能し、在庫最適化・供給計画の各モジュールへ自動的に連携されます。これがIBPの「統合」が機能する仕組みの核心です。
IBPのS&OPプロセスにおいて特筆すべき機能の一つが、変更履歴（Change History）です。計画値がいつ、誰によって、どのような値から変更されたかが自動的に記録され、後から追跡・分析できます。記録される情報には、ユーザーによる変更、変更日付、変更前後の値、理由コード、コメントが含まれます。
この機能は、単なる監査証跡に留まりません。需要予測の精度分析、ビジネス判断の有効性評価、計画ミスの再発防止という、組織の計画能力向上サイクルを支える基盤として機能します。「何が正しい計画だったのか」を事後的に検証できることは、計画組織の能力を継続的に高めるための不可欠な要件です。
IBPの操作を最も身近に感じてもらうために、需要計画担当者がExcel add-inを使って月次のコンセンサス需要を確定するまでの一連の流れを示す。
まず担当者は、ExcelリボンのIBPタブから「計画ビュー（Planning View）」を選択する。計画ビューとは、「どの品目・販売拠点を、どの時間軸で、どのキー数値を表示するか」をテンプレート化したものだ。たとえば「月次需要計画ビュー（表示期間：T+1ヶ月〜T+18ヶ月、粒度：品目×販売拠点、表示キー数値：統計的需要予測数量／前回計画値／前年同期実績）」のようなビューが事前に設定されており、担当者はそれをひとつ選ぶだけでIBP上のデータがExcelシートに展開される。
次に担当者は、各セルに表示された「統計的需要予測数量（STATISTICALFCSTQTY）」を参照しながら、販売判断を「販売予測数量（SALESFCSTQTY）」に入力する。たとえば、ある品目のT+2月の統計予測が1,200個であるのに対し、担当者が特定顧客からの大口受注見込みを把握していれば、セルに直接「1,500」と入力してオーバーライドする。変更したセルは色が変わり、理由コード（例：RC01＝顧客特需、RC02＝プロモーション効果）とコメントを入力する欄が現れる。この理由コードが、後の計画精度分析において「誰のどんな判断が当たり、外れたか」を追跡するための鍵となる。
マーケティング担当者が同様の操作でプロモーション効果を「マーケティング予測数量（MARKETINGFCSTQTY）」に入力すると、計画ビューの最終列に「需要計画数量（DEMANDPLANNINGQTY）」が自動計算で更新される。この数値がコンセンサス会議の議題となり、合意が得られた時点で需要計画数量を「コンセンサス需要（CONSENSUSDEMAND）」として確定（Publish）する。Publishボタンを押した瞬間、確定値がHANA上に保存され、供給計画モジュールへの入力として即時に利用可能な状態となる。週次のバッチ処理を待つ必要はない。
需要向けSAP IBP（IBP for Demand）は、IBPの需要管理機能を担うモジュールです。このモジュールが提供する需要管理機能は、販売事業計画などの戦略的計画から、オペレーショナル需要計画、そして短期需要計画であるデマンドセンシングまで、計画の時間軸全体にわたります。
需要向けIBPの機能は、大きく「中長期需要予測」と「デマンドセンシング（短期需要予測）」の二つに分類されます。中長期需要予測では、過去の販売履歴に基づく統計モデルを用いて、数ヶ月から数年先の需要を予測します。一方、デマンドセンシングは週単位・日次単位の短期的な需要変動を捉え、実行計画をリアルタイムで更新する機能です。
この二つの組み合わせを、カーナビゲーションシステムに例えることができます。中長期予測は地図とルートの設定（どの道を走るか）に相当し、デマンドセンシングは死角モニタリングやレーン感知など、現在の運転状況に対するリアルタイムの応答に相当します。計画と実行の両方を支援するこの二重構造が、需要向けIBPの本質的な価値です。
IBPの統計的需要予測では、複数のアルゴリズムが利用可能です。代表的なものを以下に示します。
単純平均：期間内の全履歴データの平均を使用。需要が安定している品目に適しています。
単純移動平均：直近N期間の平均を使用。トレンドの変化に比較的柔軟に対応できます。
一次指数平滑法：傾向や季節性のない時系列に適用。古いデータに低いウェイトを置きます。
二次指数平滑法：傾向が含まれる時系列に適用。トレンドの影響を管理します。
三次指数平滑法（ホルト・ウィンタース法）：傾向と季節性の両方が含まれる時系列に適用。
クロストンTSB：間欠需要（スポラジックな需要）に対応した中期予測アルゴリズム。
勾配ブースティングによるデマンドセンシング：過去のプロモーションやイベントのパターンから学習する機械学習アルゴリズム。
重要なのは、IBPが複数のアルゴリズムを「モデル」として組み合わせ、誤差測定に基づいて最も精度の高いアルゴリズムを自動選択する機能（ベストフィット選択）を持っている点です。計画担当者が毎回アルゴリズムを手動で選ぶ必要がなく、システムが継続的に精度を最適化します。
統計的需要予測が過去データに基づく「標準的な需要」を算出するのに対し、プロモーションや新製品投入・製品廃番といった「例外」を計画に反映する機能も、需要向けIBPの重要な要素です。
プロモーション統合機能では、外部のトレードプロモーション管理システムからデータを統合し、過去の販売履歴からプロモーションの影響を除いた「ベースライン需要」で統計予測を実行した上で、将来のプロモーション効果を加算する設計が可能です。これにより、プロモーション特需を含んだ精度の高い最終需要計画が生成されます。
製品ライフサイクル管理では、新製品の導入時に類似品目の販売パターンを参照製品として活用したり、フェーズアウト製品の需要の漸減を計画モデルに組み込んだりする機能が提供されます。「履歴がない新製品の需要をどう予測するか」という、多くの企業が直面する根本的な課題に対して、IBPは実践的な答えを用意しています。
デマンドセンシング（Demand Sensing）は、IBPが提供する最も先進的な機能のひとつです。週単位・日次単位の短期的な需要シグナル（POS（販売時点）データ、配送データ、受注データなど）をリアルタイムで取り込み、短期の需要予測を動的に更新します。
従来の需要計画が「今月の需要はXX万個」という月次の静的な数字であったのに対し、デマンドセンシングは「今週の需要は当初予測より15%高い傾向にある」という動的な情報を提供します。この情報は、調達・製造・物流の短期調整計画に直結し、欠品リスクや余剰在庫の発生を未然に防ぐための「早期警告システム」として機能します。
統計的需要予測のアルゴリズムは、IBPの「予測モデル（Forecast Model）」設定画面で品目セグメントごとに定義する。典型的な設定例を示す。
三次指数平滑法（ホルト・ウィンタース法）の主要パラメーター：水準平滑化係数α（0.1〜0.3：需要が安定した品目、0.3〜0.5：変動が大きい品目）、トレンド平滑化係数β（0.05〜0.2）、季節平滑化係数γ（0.1〜0.3）。α値が大きいほど直近の実績に対する感応度が高くなるため、季節性の強い消費財などでは0.3〜0.4程度に設定するケースが多い。
クロストンTSB（間欠需要向け）のパラメーター：需要量の平滑化係数α₁（0.05〜0.15）と需要頻度の平滑化係数α₂（0.05〜0.10）。出荷頻度が月に1〜2回程度のサービス部品や産業機器の補修品に適用する。α値が小さいほど過去の実績を長く参照するため、安定性重視の品目に向く。
ベストフィット自動選択の仕組み：IBPが利用可能な全アルゴリズムに対してバックテスト（過去N期間の疑似予測と実績の比較）を実行し、誤差指標が最小のアルゴリズムを自動選択する。誤差指標にはMAD（平均絶対誤差）、MAPE（平均絶対パーセント誤差）、RMSE（二乗平均平方根誤差）が選択可能であり、品目の特性に応じて使い分ける。
デマンドセンシングのパラメーターとしては、センシング対象とするシグナルデータ（POS・受注・出荷）の種類と入力頻度（日次・週次）、センシングホライゾン（通常4〜6週間先）、そして統計予測とセンシング予測を何対何の重みでブレンドするかのウェイト設定がある。たとえば「直近2週間はセンシング予測を100%採用し、3〜6週間先は統計予測との加重平均（センシング70%：統計30%）に切り替える」という設定が一般的な出発点として使われる。
需要計画が「何が、いくつ、いつ売れるか」を明らかにするのに対し、供給計画（Supply Planning）は「それをどこから、どのルートで、どのリソースを使って供給するか」を決定するプロセスです。IBPの供給計画モジュールは、顧客需要を起点として、製品のサプライチェーンを通じたフローを計算し、製造・調達・物流を含む実行可能な計画を生成します。
供給計画アルゴリズムの動作は、「需要を上流に伝播し（アップストリーム伝播）、その結果として生まれる製品の入庫・製造・調達計画を下流に展開する（ダウンストリーム展開）」という二方向の計算で成立します。サプライチェーンネットワーク全体を数理モデルで表現し、最適な物流フローを自動計算する──これがIBPの供給計画エンジンの本質です。
IBPの供給計画では、目的と制約の種類に応じて、複数の計画演算子（アルゴリズム）を使い分けます。代表的な演算子は以下のとおりです。
供給計画無限ヒューリスティック：供給の制約を考慮せず、すべての需要が充足される「無制約計画」を生成します。リソース制約のボトルネックを特定するための出発点として有効です。結果は実行不可能な場合がありますが、需要を満たすために必要な能力を明示できます。
供給計画有限ヒューリスティック：利用可能な供給に応じて需要に優先度をつけ、実行可能な有限能力計画を生成します。計画は実行可能ですが、需要の一部が充足されない（遅延納入・未納入）場合があります。
供給計画オプティマイザ：コストモデルを用いたMILP（マルチ整数線形計画法）により、コストを最小化しながら最大限に需要を充足する最適解を探索します。複雑なサプライチェーンネットワークでの高精度な計画生成に適していますが、計算に時間を要します。
この三つの演算子は、精度と計算速度のトレードオフを持ちます。実務においては、まず無限ヒューリスティックでボトルネックを把握し、有限ヒューリスティックで実行可能な計画を生成し、重要な意思決定にはオプティマイザを活用する、という段階的なアプローチが取られることが多いです。
IBPの供給計画において「サブネットワーク」は重要な設計概念です。サブネットワークとは、サプライチェーンネットワーク全体のうち、特定の計画担当者が責任を持って計画するサブセクションを指します。製品グループ別、地域別、あるいはロケーション別にサブネットワークを定義することで、大規模なグローバルサプライチェーンを分割して管理しながら、全体としての整合性は維持するという設計が可能になります。
また、シミュレーション機能を活用することで、「この入庫条件を変えたら、供給計画全体にどのような影響が出るか」を、実際にデータを保存する前に確認することができます。What-ifシナリオの検討が、計画担当者のデスクトップ上でリアルタイムに行えることが、IBPの実務的な強みの一つです。
供給計画を実行する際、計画担当者がIBP上で設定・確認する主要パラメーターを示す。
計画ホライゾン（Planning Horizon）：供給計画を何週間先まで生成するかを定義する。一般的にオペレーショナル供給計画では13〜26週（3〜6ヶ月）、戦略的S&OP計画では52〜104週（1〜2年）に設定される。
タイムフェンス（Time Fence）：実行計画（製造指図・発注済の購買）を変更しない「凍結期間」を定義する。たとえば「直近2週間は計画変更不可（Firm Zone）、3〜6週間は計画担当者の承認が必要（Trade-off Zone）、7週間以降は自動計算で更新可能（Free Zone）」という3ゾーン設定が典型例だ。
優先度ルール（Priority Rules）：有限ヒューリスティック使用時に、需要の優先順位を決める属性を指定する。得意先の戦略的重要度（Priority 1〜5）、製品のマージン貢献度、または納期の順序（先着順）など、自社のビジネスポリシーに応じて設定する。
リソース能力制約（Capacity Constraints）：生産ライン・倉庫・トラックなどのリソースに対して、稼働可能時間・容量上限を設定する。オプティマイザ使用時はこれらの制約をすべて数理モデルに組み込み、コスト最小化の計算が行われる。
実務上の操作フローは以下のようになる。計画担当者は「供給計画実行（Run Supply Planning）」ボタンを押し、使用する演算子（無限ヒューリスティック／有限ヒューリスティック／オプティマイザ）とホライゾンを選択して実行する。計算はHANA上でリアルタイムに行われ、数百品目・数十拠点の計画であれば通常数十秒〜数分で完了する。結果はキー数値「計画された供給（Planned Supply）」「在庫見込み（Projected Inventory）」として計画ビューに反映される。充足できなかった需要は「未充足需要（Unconstrained Demand vs. Constrained Demand のギャップ）」として可視化され、担当者がボトルネックを特定してトレードオフの意思決定を行う。
在庫は、企業がサプライチェーンの不確実性に対応するための「バッファ」です。しかしそのバッファを持つことには当然コストが伴います。在庫に関連する主要なコストには、在庫保管費用（資本コスト）、在庫廃棄リスク（陳腐化・品質劣化）、保管コスト（倉庫設備維持費）、補充指図準備コストが含まれます。
一方で在庫が少なすぎると、欠品による機会損失、顧客サービスレベルの低下、そして緊急調達コストが発生します。「過剰在庫」と「欠品」の同時回避──これが在庫管理における永遠の命題であり、在庫向けIBPが科学的に解決しようとする課題です。
IBPの在庫最適化を正しく活用するためには、在庫をその目的別に分類して理解することが重要です。
サイクル在庫：補充サイクルから生まれる在庫。発注コストと保管コストの経済的バランスから最適な発注量が決まります。
安全在庫：需要または供給の不確実性から企業を保護するための在庫。「見えない変動」に備えるバッファです。
予測在庫：将来発生するイベント（季節需要・生産停止など）に備えて事前に積み増す在庫です。
パイプライン在庫：サプライチェーンネットワーク内のロケーション間で輸送中の在庫です。
季節在庫：需要ピーク時の能力制約から生まれる、事前製造された在庫です。
IBPの在庫最適化が主に対象とするのは「安全在庫」の設定です。いかに少ない安全在庫で、目標とするサービスレベルを達成するか──この問いに対して、IBPは統計的・数理的な手法で答えを提供します。
在庫向けIBPの最大の差別化要因は「多段階在庫最適化（Multi-Echelon Inventory Optimization）」です。従来の在庫管理では、各拠点（工場・物流センター・販売拠点）が独立して安全在庫を設定していました。この「拠点個別最適化」のアプローチは、ネットワーク全体での在庫の重複（バッファの二重保有）を招き、総在庫費用を不必要に高めます。
多段階最適化では、サプライチェーンネットワーク全体を一つのモデルとして捉え、需要の不確実性・供給リードタイムの変動・各拠点のサービスレベル目標を統合的に考慮した上で、ネットワーク全体として最小コストとなる安全在庫の配置を算出します。「どの拠点にどれだけ在庫を持つべきか」という問いを、全体最適の視点で答えるのです。
IBPの在庫最適化エンジンは、正規分布・ガンマ分布をはじめとする統計的モデルを使用して需要変動を分析し、需要伝播・サービス変動・供給変動を計算した上で、目標在庫量（Target Stock Level）を算出します。この計算結果が、S&OPプロセスへの入力として機能し、供給計画との整合性を保ちながら在庫計画が確定されます。
すべての品目を同一の基準で管理することは現実的ではありません。IBPの在庫最適化では、ABC分析（売上・利益への貢献度による分類）とXYZ分析（需要の変動係数による分類）を組み合わせた、セグメンテーション機能が提供されます。
高価値で需要が安定したA×X品目と、低価値で需要が不規則なC×Z品目では、最適な在庫管理アプローチが根本的に異なります。このセグメンテーションを計画モデルに組み込むことで、重点管理が必要な品目に計画リソースを集中させ、効率的な在庫計画が実現します。
在庫向けIBPが安全在庫を算出するために必要なパラメーターと、その設定の実務を示す。IBPの安全在庫計算の基本式は以下のとおりだ。
各変数の意味は次のとおりである。Z(SL)はサービスレベルに対応する標準正規分布のZ値（サービスレベル90%=1.282、95%=1.645、99%=2.326）、LTは平均リードタイム、σDは需要の標準偏差（需要変動リスク）、Dは平均需要量、σLTはリードタイムの標準偏差（供給変動リスク）を表す。
IBPでこの計算を実行するために担当者が設定するパラメーターは以下のとおりだ。
サービスレベル目標（Target Service Level）：品目セグメント別に設定する。たとえばA×X品目（高価値・安定需要）は95%、B×Y品目は90%、C×Z品目（低価値・不規則需要）は80%というように、セグメントに応じて段階的に設定する。
需要変動計測期間：過去何ヶ月の販売実績をもとに需要の標準偏差σDを算出するか。通常12〜24ヶ月を使用するが、季節性が強い品目ではサイクル全体を捉えるために24ヶ月以上を指定することもある。
リードタイムと変動係数：調達リードタイムLTとその標準偏差σLTは、サプライヤマスタまたはロケーションプロダクトマスタに入力する。たとえば「平均LT=28日、σLT=5日」という入力値から、供給リスク起因の安全在庫が自動計算される。
目標在庫水準（Target Stock Level）：算出された安全在庫に、補充サイクル中に消費される在庫（サイクル在庫の半分）とパイプライン在庫を加算したものが目標在庫水準として出力される。この数値がS&OPプロセスへの入力として供給計画モジュールに連携される。
多段階最適化（Multi-Echelon）実行後には、「在庫最適化結果ビュー」に各拠点の現在の安全在庫、計算された推奨安全在庫、その差（削減可能量）が品目単位で一覧表示される。たとえば「現在の安全在庫：500個、推奨：320個、削減可能量：180個（在庫金額換算：XXX万円相当）」というような形で、改善機会が定量化されて提示される。
IBPがリアルタイムのシナリオ計画・大規模データ処理を実現できる技術的背景は、SAP HANAというインメモリデータベースプラットフォームにあります。従来のディスクベースデータベースでは、大量データの集計・計算に数分から数時間を要していた処理が、HANAでは秒単位で完了します。
IBPの計画データはすべてHANA上に格納され、計算もHANA内で完結します。これにより、「計画担当者がExcelで数値を入力したその瞬間に、サプライチェーン全体への影響が計算される」というリアルタイム性が実現されます。大規模なデータボリュームと複雑な計算を処理しながら、計画担当者が「待つ」時間をほぼゼロにする──これがHANAがIBPにもたらす本質的な価値です。
IBP for Supply Chainはクラウドで提供されます。オンプレミス（自社データセンター）への導入はなく、SAPが管理するクラウド環境上で稼働します。このクラウド提供モデルには、重要な含意があります。
第一に、インフラ投資が不要です。高価なサーバー設備の調達・設置・運用管理をSAPが担うため、企業はソフトウェアのライセンス費用のみで最先端の計算環境にアクセスできます。第二に、機能更新が四半期ごとに自動的に行われます。IBPは年4回のリリースサイクルで機能が追加・改善されており、企業は常に最新の機能を利用することができます。第三に、グローバル展開の俊敏性です。新たな拠点や地域へのIBP展開は、オンプレミスのように物理インフラを準備する必要がなく、設定変更のみで対応できます。
IBPのユーザーインターフェースは、計画担当者の多様なニーズに対応するために、二つのUIが提供されています。
一つ目は「SAP IBP, add-in for Microsoft Excel」です。計画担当者が日常的に使い慣れたExcelの操作感のまま、IBPのデータにアクセスし、計画値を入力・修正できます。ExcelリボンにIBPのタブが追加され、システムとのリアルタイム接続が維持されます。計算はHANA上で実行されるため、ローカルのExcel処理ではなく、大規模データを秒単位で処理した結果が即座に表示されます。
二つ目は「Planner Workspace（PWS）」と呼ばれるWebベースのUIです。ブラウザから直接アクセスでき、カスタムアラート・シミュレーション・分析機能を備えた設定可能な作業環境です。Webの特性を活かした新しいユースケース（モバイルアクセスなど）や、他のSAP Fioriアプリとの統合が可能です。
この二つのUIが並行して提供されていることは、重要な示唆を持ちます。ExcelはMicrosoftの「普遍的な言語」であり、計画担当者が新たなツールを覚えることなくIBPを使い始められる敷居の低さを実現します。一方でWebUIは、将来的なモバイルワークやより高度な分析・コラボレーション機能への拡張性を担保します。
IBPを理解する上で、「計画範囲（Planning Area）」という概念は避けて通れません。計画範囲とは、IBPの計画モデル全体を定義する枠組みです。何のデータを、どのような次元（製品・得意先・ロケーション・時間軸）で管理し、どのような計算ロジックで処理するかが、計画範囲の設定によって決まります。
SAPは、各モジュール（S&OP、需要、在庫、供給）に対応したサンプル計画範囲（SAPIBP1、SAP3、SAP4、SAP6など）を標準で提供しており、これをコピー・カスタマイズして自社の計画モデルを構築するアプローチが推奨されます。ゼロから計画範囲を構築することも技術的には可能ですが、サンプル計画範囲の活用により、構築期間の大幅な短縮が実現します。
IBPのマスタデータは、「単純マスタデータ」と「複合マスタデータ」の二種類に分類されます。単純マスタデータには、製品（Product）・得意先（Customer）・ロケーション（Location）・リソース（Resource）・計画単位（Planning Unit）が含まれます。複合マスタデータは、これらの組み合わせで定義されます。例えば「ロケーションプロダクト（Location-Product）」は、特定のロケーションにおける特定の製品の属性を管理するための複合マスタデータです。
供給計画においてとりわけ重要なのが「供給元決定ルール（Sourcing Rules）」です。得意先の需要をどのロケーションから何パーセントで充足するか（Cルール）、ロケーション間の在庫転送（Tルール）、製造ルール（Pルール）を定義することで、サプライチェーンネットワーク全体の物流フローが計算されます。このマスタデータの設計品質が、供給計画の精度を大きく左右します。
IBPにおける「キー数値（Key Figure）」は、時間の経過に伴う一連のデータ値です。販売予測数量・コンセンサス需要・統計的需要予測・在庫残高・能力計画など、計画プロセスで扱われるすべての数字がキー数値として定義されます。
キー数値には「保存値（Stored）」と「計算済（Calculated）」の区別があります。保存値は計画担当者が入力・変更する値であり、計算済は他のキー数値から自動的に算出される値です。この設計により、ある値を変更した際の「連鎖計算」が自動的に実行され、計画全体の整合性が維持されます。
需要モジュールの標準的なキー数値の流れを例に示すと、「統計的需要予測数量（STATISTICALFCSTQTY）」→「販売予測数量（SALESFCSTQTY）」→「マーケティング予測数量（MARKETINGFCSTQTY）」→「需要計画数量（DEMANDPLANNINGQTY）」→「コンセンサス需要（CONSENSUSDEMAND）」という流れで、各部門の判断が数値として積み上げられ最終合意値に収束します。この透明なデータフローが、「誰がどの数値を責任を持って管理するか」を明確にし、計画プロセスのガバナンスを支えます。
IBPの計画範囲（Planning Area）を設計する際に、コンサルタントと企業の担当者が確認・設定する主要パラメーターを示す。
プランニングホライゾン（Planning Horizon）：計画データを何ヶ月先まで保持するかを定義する。S&OP向け計画範囲（SAPIBP1）では通常24〜36ヶ月、供給計画向け（SAP6）では12〜26週が標準値として設定される。企業の意思決定サイクルと調達リードタイムに合わせて調整する。
タイムバケット（Time Bucket）：計画データを集計する時間単位を定義する。S&OPは月次（TP_MONTH）、需要センシングや供給計画は週次（TP_WEEK）または日次（TP_DAY）が一般的だ。計画範囲には複数のタイムプロファイルを混在させることができるため、S&OPの月次見通しと実行計画の週次詳細を同一計画範囲内で扱うことも可能だ。
計画レベル（Aggregation Levels）：キー数値がどの次元の粒度で管理されるかを定義する。たとえば「統計的需要予測数量」は品目×販売拠点×月次（最細粒度）で計算され、計画ビュー上では製品グループ×国×四半期という集計レベルで表示される、という多階層の集計が自動的に行われる。
バージョン管理（Versions）：IBPは計画データにバージョン（シナリオ）の概念を持つ。「アクティブバージョン（実計画）」に加えて複数のシナリオバージョンを作成でき、たとえば「楽観シナリオ（需要+20%）」「悲観シナリオ（供給制約継続）」を並行して計算・比較した上で、経営判断の材料として提示することができる。
キー数値の設定においては、「保存値（Stored）」と「計算済み値（Calculated）」の区別が設計の要点となる。保存値は計画担当者がExcelから入力・変更する値であり、計算済み値はその保存値をもとにIBPが自動で算出する値だ。たとえば「コンセンサス需要（CONSENSUSDEMAND）＝ 需要計画数量（DEMANDPLANNINGQTY）× 承認フラグ付きキー数値」という計算ロジックを計算済みキー数値として定義すると、担当者が承認フラグを立てた瞬間に自動集計が走り、供給計画への入力値が更新される。この「どの数値を誰が入力し、何が自動計算されるか」の設計こそが、IBPデータモデル設計の核心であり、導入コンサルタントが最も時間をかけて企業のビジネスプロセスに合わせて作り込む部分に他ならない。
IBPの展開において最も重要な原則は「ビジネスの優先事項に基づいてデプロイする」ことです。技術的に美しいフルスコープの実装を一度に目指すことは、往々にして経営のコミットメント不足・現場の混乱・プロジェクト遅延を招きます。
実績のある展開アプローチは、最も痛みの大きいビジネス課題を起点に、最小限のスコープでIBPの価値を短期間で実証することです。例えば、「需要と供給の同期が取れていない」という課題がある場合は、S&OPモジュールから着手し、月次の計画会議の質を変えることに集中します。その成功事例を足がかりに、次のモジュール展開への経営承認を得るという段階的なアプローチです。
IBPとS/4HANA（またはECC）の関係を理解することは、展開戦略を立案する上で不可欠です。IBPは計画系（Plan）のシステムであり、S/4HANAは実行系（Execute）のシステムです。IBPで生成された計画は、S/4HANAの実行計画（製造指図・購買発注・在庫移動）として具体化され、その実績データが再びIBPに戻ってきて次の計画サイクルに使われます。
このPlan（計画）→Execute（実行）→Monitor（監視）→Adjust（調整）というサイクルを、IBPとS/4HANAが役割分担して回すことが、SAP供給チェーンソリューション全体の設計思想です。IBPを単体で見るのではなく、S/4HANAとの組み合わせで初めてその真価が発揮されることを理解した上で、展開設計を行うことが重要です。
IBPの価値を最大化するためには、高品質なデータの継続的な供給が不可欠です。需要計画に用いる販売実績データ、供給計画に用いるリードタイム・調達率・BOM（部品表）データ、在庫最適化に用いるサービスレベル目標・コストデータ──これらが不正確・不完全であれば、いかに精緻なアルゴリズムを適用しても、計画の質は高まりません。
「Garbage In, Garbage Out（ゴミが入ればゴミが出る）」はIBP導入においても変わらぬ真実です。IBP展開の初期フェーズにおいて、データの品質評価と整備に十分な投資を行うことは、プロジェクトの成否を分ける最重要ファクターの一つです。
IBPが正しく機能したとき、組織に生じる最大の変化は「議論の質の変容」です。各部門が異なる数字を持ち寄り、「なぜ数字が合わないのか」の解明に会議時間を費やす状態から、「共通の数字を前提として、どのトレードオフを選択するか」というビジネス上の本質的な議論に集中できる状態へと移行します。
この変化は表面的には些細に見えますが、経営へのインパクトは甚大です。需給調整会議に費やされる時間が削減される。意思決定のリードタイムが短縮される。「なぜ欠品が起きたのか」の根本原因がデータから素早く特定できる。これらの積み重ねが、企業の市場への応答速度と意思決定の質を根本から変えていきます。
IBPのシナリオ計画機能は、「もしXXが起きたら、どうなるか」をデータで瞬時に試算する能力を組織に与えます。為替レートが10%変動した場合の収益への影響、主要サプライヤが1ヶ月間供給停止した場合の在庫への影響、新製品の需要が計画比150%で推移した場合の供給能力の充足率──こうした「不確実な未来のシナリオ」を事前に計算し、対策を準備しておくことができます。
「先を読む力」は、経営の最も重要な能力の一つです。IBPのシナリオ計画機能は、その能力をデータに裏打ちされた形で組織に付与する仕組みです。
IBPが実現する変革の一つに「計画の民主化」があります。従来、サプライチェーン計画は専門家（プランナー）のみが扱う高度な領域でした。しかしIBPは、Excelという馴染みのあるツールを通じて、営業担当者・マーケティング担当者・財務担当者・製造担当者が同一の計画プロセスに参画できる環境を提供します。
営業担当者が自分の担当顧客の販売予測を入力し、その影響がリアルタイムでサプライチェーン全体に反映される。マーケティング担当者がプロモーション計画を登録し、需要への影響が即座に供給計画に伝わる。この「リアルタイムコラボレーション」こそが、IBPが真の意味でビジネスプロセスを変革する瞬間です。
本稿を通じて解説してきたIBPの本質を、最後に一言で総括します。IBPとは、サプライチェーンの需要・供給・在庫・財務を統合する「計画の仕組み」です。
IBPを「SAPが提供するプランニングソフトウェア」と理解するのは正しくありません。IBPとは、組織全体の計画プロセスを再設計し、データを共通言語として経営の意思決定を変革するための「経営の仕組み」です。その仕組みを機能させるためには、適切なシステム設計はもちろんのこと、経営陣のコミットメント、各部門のビジネスオーナーシップ、そして継続的なプロセス改善が不可欠です。
IBPの導入は、ゴールではなく出発点です。正しく導入され、正しく運用されたとき、IBPは企業のサプライチェーンを競争優位の源泉へと変えるための、最も強力な経営インフラとなります。その可能性を最大限に引き出すために、本稿が一助となれば幸いです。
IBPの概念的な理解と、それが実際のビジネス現場でどう機能するかの間には、常に一定のギャップが存在します。本章では、SAP IBPを実際に導入した企業の事例を通じて、そのギャップを埋めることを試みます。以下の二事例はいずれも公開資料に基づく実在の導入事例であり、企業名は匿名としています。
国内に拠点を置く業務用音響・映像機器メーカー（国内外に5製造拠点を持ち、世界120ヵ国以上に製品を販売。連結売上高は数百億円規模）。業務用スピーカー・マイクロフォン・映像機器に加え、近年はセキュリティ機器やネットワーク機器へと事業領域を拡張している。海外ではアジア・パシフィック地域を中心に事業規模を拡大しており、拠点別に現地法人・販売会社を通じた世界120ヵ国超への販売体制を敷いている。
同社のサプライチェーンは、2つの製造拠点と、インドネシア・シンガポール・オランダの3拠点からなる在庫拠点が組み合わさった複雑な構造を持つ。このネットワークを通じて4,000品目以上の商品が世界の販売会社に届けられており、PSI（生産・販売・在庫）計画の複雑性は業務上の大きな負荷となっていた。
IBP導入以前、同社の計画プロセスは週次バッチ処理のExcelマクロで運用されていた。この方式の構造的限界は明らかであった。計画データの更新に時間を要するため、市場の需要変動に対してタイムリーに対応することが困難だった。販売実績・在庫実績・販売予測のデータが複数のシステムに分散しており、それらを手作業で集約・照合する作業に多大な工数が割かれていた。さらに深刻だったのは、「販売量ベースの売上計画」と「数量ベースの生産・在庫計画」とのあいだに乖離が生じやすい構造的な問題だった。販売部門は金額ベースの予測を立て、製造部門は数量ベースで計画する。この「二つの言語で語られる計画」が、数値の突き合わせを困難にし、過剰在庫と欠品の同時発生につながっていた。
この状況にCOVID-19が追い打ちをかけた。世界的なサプライチェーンの混乱は、半導体・電子部品の調達難という形で同社にも直撃し、部品調達の逼迫と在庫・出荷管理の混乱が重なる中で、既存の計画プロセスの限界が決定的に露呈した。
PSIツールの刷新を検討するにあたり、同社はSAP IBPを選定した。その決め手は、既存の基幹システムがSAP ERPであったこと──20年以上の稼働実績を持つSAPシステムとのデータ連携においてネイティブな親和性があること──そして、クラウドベースのため短期間での導入が可能であり、四半期ごとの継続的な機能拡張が受けられる点であった。
導入したソリューションはSAP IBP for Sales and OperationsとSAP Supply Chain Control Tower（SCCT）の組み合わせ。実装パートナーとして選定されたのは、SAPソリューションに深い知見を持つシステムインテグレーターである。プロジェクトは2023年3月に開始され、2024年1月に本番稼働を迎えるまで、約10ヵ月で完了した。
導入プロセスでは、まずシステムインテグレーターのデモ環境でSAP IBPの標準設計思想（Fit to Standard）を確認するステップを経た後、プロトタイプフェーズで在庫計画・需要計画・生産計画の各プロセスにおけるギャップ分析が丁寧に行われた。複数のシステム間をまたがる業務仕様の整理が丁念に行われたことが、プロジェクトをスケジュール通りに完了させた要因のひとつとなっている。
本番稼働後、最も顕著な成果として現れたのは計画サイクルの抜本的な短縮である。それまで週次でしか回せなかったPSI計画のサイクルが、日次で実行できるようになった。これは単なる「計画頻度の増加」ではない。市場の需要変動や供給上のイベントに対して、翌日には計画が修正・更新されるという、応答速度の次元そのものが変わったことを意味する。
またシステムの標準機能に基づく業務の標準化が実現したことで、特定の担当者の経験・知識に依存していた計画プロセスが、誰でも一定の品質で実行できる仕組みへと転換された。「属人的な計画」から「組織の計画プロセス」への移行──これこそが、IBP導入が組織にもたらした最も本質的な変革といえる。
さらに、SAP Supply Chain Control TowerとIBPを組み合わせた活用により、販売予測と在庫実績の乖離をリアルタイムで把握し、過剰在庫・欠品リスクを前もって検知して営業部門への情報提供が可能になっている。現在同社は、IBPの適用範囲を海外販売子会社にも拡大し、グループ全体でのS&OP推進を次の目標に掲げている。
米国カリフォルニア州に拠点を置く農産物協同組合（世界最大規模のアーモンド生産者団体であり、組合員農家から集荷した農産物を加工・販売するビジネスモデル。バルク品の卸売にとどまらず、消費者向けのパッケージ製品の製造・販売にも事業を拡大している）。製品は複数の大陸の小売チャネルを通じて世界中に販売されており、その複雑な需給バランスの管理が、事業拡大とともに経営上の重要課題となっていた。
同組合がSAP IBPの導入を決断した背景には、事業の成長がもたらした「複雑性の爆発」があった。農産物バルク品の販売という比較的シンプルなビジネスモデルから、消費者向けパッケージ製品の製造・多チャネル販売へと事業が拡張するにつれ、サプライチェーンの複雑度は飛躍的に増大した。
最大の問題は計画ツールの断片化であった。複数のシステムとスプレッドシートが混在する計画環境では、需要予測の作成そのものが困難であり、計画担当者の大半の時間がデータの集約・突合・転記という非付加価値作業に費やされていた。「計画」するための時間よりも「データを整える」時間の方が長いという状態は、スケールする事業に対応できる組織能力の構築を阻害していた。
同組合はSAP IBPの導入をグローバルコンサルティングファームの支援のもとで実施した。既存のオンプレミスSAPシステムとの統合を維持しながら、クラウドベースのIBPをサプライチェーン計画の中枢に据えるというアーキテクチャが採用された。これにより、基幹業務データとの整合性を保ちながら、IBPの高度な計画機能を活用できる環境が構築された。
IBP稼働後6ヵ月以内という早期に、需要予測精度が10%改善するという定量的な成果が確認された。この数字は、IBPの統計的需要予測アルゴリズムと、システム上で標準化されたコンセンサス計画プロセスが機能した結果である。予測精度の向上は、過剰在庫と欠品リスクの両方を同時に低減する効果を持つ──10%という数値は一見地味に見えるかもしれないが、年間取扱量が大規模な農産物協同組合においては、在庫削減と機会損失回避の面で多大な財務的価値をもたらすものだ。
さらに大きな変化は、計画担当者の業務内容の転換であった。データ収集・突合・転記という作業から解放された計画担当者は、戦略的なビジネス分析と意思決定支援という、より高次の業務に時間とエネルギーを振り向けられるようになった。「計画担当者をデータ管理者から、意思決定者のパートナーへ転換する」というIBPの本来の価値が、この事例で如実に表れている。
同組合がIBPの真価を最も強く実感したのは、COVID-19パンデミックへの対応局面においてであった。サプライチェーンの混乱と需要パターンの急変が重なる中、同組合はシナリオプランニング機能を活用した「Supply Chain Scenario Planning-as-a-Service」の仕組みを迅速に展開し、計画サイクルを従来の月次・週次から日次へと切り替えることに成功した。平時であれば数週間を要するはずの計画サイクルの抜本的変更を、IBPというデジタル基盤があったからこそ、事業継続を維持しながら実行できたのである。
業種・規模・地域は異なる二社の事例であるが、IBP導入の経緯と成果には共通する構造が見て取れる。まず「課題の本質が計画の断片化にある」という点で両者は一致している。ExcelやバラバラなシステムによるPSI管理は、どちらの企業においても「データを集める作業」が「計画を考える作業」を圧倒するという機能不全を生んでいた。
次に、IBP導入の最初の定量的成果として現れているのが「計画サイクルの短縮」と「予測精度の向上」であることも共通している。週次から日次への計画サイクルの変化、6ヵ月以内での予測精度10%改善という成果は、いずれもIBPが「計画の速度と精度」を根本から変えることを示す実証データである。
そして最も重要な示唆は、危機の局面においてIBPの真価が顕在化するという点だ。COVID-19というかつてない規模のサプライチェーン混乱を前に、両社はIBPを基盤として計画プロセスの迅速な再設計を実現している。「平時に導入した仕組みが、有事の対応力を決める」──これが、IBPを「経営の仕組み」として構築することの、最も本質的な意義に他なりません。
以上