月曜の朝、購買の担当者がExcelの在庫表を開き、今週の発注量を決めていく。
先月は部品が欠け、今月は倉庫に在庫が積み上がった。
担当者の勘に頼る発注は、欠品と過剰在庫を交互に生みます。
NetSuiteのSupply Planning（MRP）とは、需要に対して「何を・いつ・どれだけ」用意するかを計算し、発注や製造の提案を作る機能です。
MRPは「Material Requirements Planning（資材所要量計画）」の略です。
これから使う会社は、MRPが前提になります。
旧来のTime-Phased Planningを使っている会社には、移行の計画が要ります。
ただ、MRPを入れた会社がみな、欠品と過剰から抜け出せるわけではありません。
では、同じ機能で差がつくのはどこか。
この記事で分かること
- Supply Planning（MRP）が計算するものと、できること
- Time-Phased Planningとの関係と、Oracleの公式の見解
- MRPが向く会社・向かない会社と、導入の費用を左右するもの
- 新しく使う会社と、移行する会社の進め方
- 供給計画でつまずく3つの失敗
Supply Planning（MRP）の位置づけ
NetSuiteの計画は、3つの段階に分けると見通しがよくなります。
- 需要計画：これから何が、どれだけ売れそうかを見立てる
- 供給計画（MRP）：その需要に対して、何をいつ仕入れ・作るかを決める
- 受注・出荷：実際の注文を処理する
MRPは真ん中の段階です。
需要の見通しを受け取り、発注書・作業オーダー・転送オーダーの提案に変えます。
作業オーダーは製造の指示、転送オーダーは拠点の間で在庫を動かす指示のことです。
3つの段階を図にすると、次のとおりです。
需要の見立て方は、NetSuite需要予測の4つの手法で扱っています。
Time-Phased Planningとの関係
Oracleの公式の見解
Oracleのヘルプには、次のように書かれています。
- MRPはTime-Phased Planningを置き換え、より多くの機能と良い性能を提供する
- 新しい顧客はMRPを使う
- 既存の顧客は、Time-Phased PlanningからMRPへの移行を計画する
（出典：Oracle NetSuiteヘルプ、2026年9月確認）
拠点の間の補充を計画するDRP（流通所要量計画）にも、ヘルプは触れています。
DRPはTime-Phased Planningの一部で、すでにサポートされていない。
その役割は、MRPの計画ルール（Planning Rules）に置き換えられた、という説明です。
（出典：Oracle NetSuiteヘルプ、2026年9月確認）
計画のやり方3つ
| やり方 | 中身 | 向く状況 | 注意点 |
|---|---|---|---|
| A. Excelと担当者の勘 | 在庫表と経験で発注量を決める | 品目が少なく、需要が安定 | 担当者が替わると回らない。根拠がデータに残らない |
| B. Time-Phased Planning | 旧来の計画の方式 | すでに使い、当面は回っている | 公式にサポートされていない。移行の計画が要る |
| C. Supply Planning（MRP） | 計画の定義に沿って、提案とメッセージを出す | 品目・拠点が多い、多段のBOMがある | 前提の機能とデータの準備が要る |
MRPの提案や例外のメッセージは、NetSuiteの中にデータとして残ります。
「どの提案が放置されているか」「どの品目で例外が多いか」。
こうした点検は、AIに任せやすい作業です。
Excelに散らばった計画では、この点検から始められません。
Supply Planning（MRP）でできること
Oracleのヘルプと製品ページに載っている機能は、次のとおりです（2026年9月確認）。
| 機能 | できること |
|---|---|
| 計画の定義 | 計画する期間（日数）・拠点・需要の種類・品目のグループ・計画ルールを決め、定期的に自動で実行する |
| What-if（仮説の検討） | 計画をコピーして条件を変え、複数の計画を比べる |
| ワークベンチ | 計画オーダーを確認・修正・作成・リリースする。前倒し・後ろ倒し・取消の提案を処理する |
| ペギング | 需要と供給のつながりを、階層をたどって追う |
| 供給アロケーション | 手元の在庫と入荷予定の在庫を、需要に割り当てる |
| 複数拠点の計画 | 複数の拠点を同時に計画する。拠点の間の移動は計画ルールで扱う |
出典は計画の定義、概要、ワークベンチ、供給アロケーションの各ヘルプです。
言葉を3つ補います。
- ワークベンチは、製品ページでPlanners Workbenchと呼ばれる計画担当の作業画面です。不足や過剰が起きそうな箇所を示します
- ペギングとは、需要と供給をひもづけて追うことです。「この部品の不足は、どの受注が原因か」をたどれます
- 供給アロケーションでは、発注書・転送オーダー・作業オーダーの入荷予定も対象にできます。注文を満たせる最も早い日も分かります（出典：Oracle NetSuite公式 MRP）
使う前にそろえる前提
有効にする機能
Oracleのヘルプでは、MRPを使うために次の機能を有効にするよう案内しています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
- ロケーション、複数ロケーション在庫
- 組立品目、高度な部品表（BOM）、作業オーダー
- 高度な在庫管理（Advanced Inventory Management）
- Material Requirements Planning
対象の品目は、補充の方法を「Material Requirements Planning」に設定します。
計画が回る流れ
公式ヘルプの概要をもとにすると、1回の計画は次の順で回ります（出典：Oracle NetSuiteヘルプ）。
- 取引・需要計画・BOMなどを、計画用のデータの置き場（Planning Repository）に取り込む
- 計画の定義に沿って計画を実行する
- ワークベンチで、推奨と例外のメッセージを読む
- 計画オーダーを確定・リリースし、発注書や作業オーダーを作る
- 前倒し・後ろ倒し・取消の変更を承認する
取り込みの頻度は、自社で決められます。
取り込みが古いと、古いデータで計画が出ます。
「いつ取り込み、いつ計画を回すか」を、業務の決まりにしておきます。
土台のデータ
MRPは、登録されたデータから計算します。
計画の質は、次のデータの精度で決まります。
- 品目ごとのリードタイム（発注から入荷までの日数）
- 安全在庫の基準
- BOMの正確さ
冒頭の問いの答えは、ここにあります。
同じMRPでも、この3つが古い会社では、提案が現実と合いません。
差をつけるのは機能ではなく、土台のデータと、提案を見る人の決まりです。
安全在庫の考え方は、在庫最適化とはで扱っています。
判断の物差し｜MRPが向く会社・向かない会社
| 条件 | 向いている | いまは入れなくてよい・別の選択肢 |
|---|---|---|
| 品目と拠点 | 品目が多い、複数の倉庫・工場がある | 品目が少なく、拠点が1つ |
| 製造の形 | 多段のBOMで組み立てる | 仕入れて売るだけで、発注点で足りる |
| データ | リードタイムとBOMを保守できる | BOMが担当者の頭の中にしかない |
| 計画の担当 | 提案を毎週見る人を置ける | 見る人を置けない |
向かない条件が多い場合の道は、3つあります。
- いまは入れない：まずBOMとリードタイムを整える。それだけで発注の精度が上がることもあります
- 発注点の運用で足りる：NetSuiteの在庫管理の範囲で回す（NetSuiteの在庫管理でできること）
- 製造の現場を深く作り込みたい：国産の生産管理システムや、Odoo、AIスクラッチ開発と比べる
導入の費用と期間を左右するもの
MRPは、在庫・購買・製造の機能とそろって動きます。
そのため費用と期間は、MRPだけでなく、導入全体の中身で決まります。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットが支援したNetSuite導入の費用で見てみます。
3名程度・購買と販売だけ・開発なしの事例は、1.5か月・150万円程度でした。
100名程度で購買・販売・在庫・会計に外部システムとの連携開発を加えた事例は、1.5年・2億円程度（うち開発約7割）です。
差を生むのは、機能範囲・開発（特に外部連携）・社内の体制・ユーザー数の4つ。
MRPを使う会社は在庫と製造まで範囲に入るため、機能範囲の広い側に寄ります。
4つの事例の全体は、NetSuiteの料金・費用で紹介しています。
読者の二つの立場
これから使う会社
- 前提の機能と、土台のデータを整える
- 主要な品目・拠点だけで計画を定義する
- ワークベンチを見る担当と頻度を決めてから、対象を広げる
Time-Phased Planningを使っている会社
公式ヘルプでは、Time-Phased Planningはサポートされていないと説明されています。
「いつか」ではなく、移行の時期を計画に入れる段階です。
手戻りを減らす順番は、次の4つです。
- いまの計画で、誰が何を見て発注しているかを書き出す
- 品目ごとの補充の方法と、計画のパラメータを棚卸しする
- 主要な品目だけで、MRPの計画を並行して回す
- 両方の提案を比べ、差の理由をつかんでから切り替える
並行の期間は、サンドボックス（本番と別の試験用の環境）の使い方も検討します。
拠点の間の補充をDRPで回している場合は、別の論点があります。
MRPの計画ルールで同じ動きを作れるかを、切り替えの前に試しておきます。
導入を支援したパートナーと移行の話が進まない場合は、パートナー変更という選択肢もあります。
よくある3つの失敗
失敗1：土台のデータが曖昧なまま計画を回す
起きること：提案された発注量が現実と合わず、現場が提案を見なくなる。
原因：リードタイム・安全在庫・BOMが古いまま、MRPを動かした。
避け方：計画の前に、主要な品目のデータを点検します。
順番を逆にしないことです。
失敗2：最初から全品目・全拠点に広げる
起きること：ワークベンチの提案と例外が多すぎて、処理しきれない。
原因：「せっかくなら全部」と対象を広げた。
避け方：品目のグループと拠点を絞って始めます。
処理が回ってから広げます。
失敗3：メッセージを誰も見ない
起きること：前倒し・取消の提案が放置され、「Excelの方が早い」と元に戻る。
原因：誰が、いつ、何を基準に処理するかを決めていない。
避け方：担当・頻度・判断の基準を、稼働の前に決めます。
導入全般のつまずきは、ERP導入はなぜ失敗するのかで扱っています。
ベンチャーネットならこう見る
「MRPを入れれば、発注は自動で決まる」
相談の場で、そう期待されることがあります。
ベンチャーネットの答えは、少し違います。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応する立場で見ると、先にやることがあります。
設定の話より先に、いまの発注の仕方を見える化することです。
型1：見える化→整理整頓→Fit&Gap
- 見える化：誰が、どの表を見て、いつ発注しているかを現場に聞いて描く
- 整理整頓：もう動いていない品目や、形だけの安全在庫を片付ける
- Fit&Gap：残った品目の補充の考え方を、MRPの標準機能と照らし合わせる
Fit&Gapは、業務と機能の合う・合わないを一つずつ見る作業のことです。
2段目で品目を絞ると、計画の対象もワークベンチのメッセージも減ります。
失敗2を避ける近道にもなります。
型2：標準に合わせる／開発する／残す
MRPの標準で収まらない部分は、3つのどれかに決めます。
- 標準に合わせる：補充の考え方を、MRPの計画の定義と計画ルールに寄せる
- 開発する：画面や帳票の不足を、NetSuiteリブート（ベンチャーネットのアドオン開発）で補う
- 残す：MRPに載せにくい品目は、当面は発注点の運用で続ける
開発を選ぶほど、導入の費用も稼働後の保守も重くなります。
5-1で見た「開発」の要因は、ここで決まります。
あわせて、変わることも先にお伝えします。
計画の担当は、Excelではなくワークベンチを毎週見ることになります。
新しい機能は、提供の時期と自社のアカウントで使えるかを担当に聞いてから計画に入れます。
最初の打ち合わせで伺うのは、次の3つです。
- 欠品と過剰の、どちらが痛いか
- BOMとリードタイムを、誰が保守するか
- ワークベンチを見る人を置けるか
今日できること
欠品か過剰が起きた品目を1つ選び、次の3つを書き出してください（1時間以内）。
| 項目 | 登録されている値 | 実際の値 |
|---|---|---|
| リードタイム | ||
| 安全在庫 | ||
| BOMの部品数 |
登録と実際がずれている品目が多いほど、MRPの前にデータの整備が要ります。
よくある質問
Q1. MRPとTime-Phased Planningはどう違いますか
MRPはTime-Phased Planningを置き換える後継の方式です。
公式ヘルプでは、MRPの方が機能と性能が上とされています。
新しい顧客はMRPを使うよう案内されています。
Q2. Time-Phased Planningを使っています。すぐ移行が必要ですか
移行の時期を計画に入れる段階です。
公式ヘルプでは、Time-Phased Planningはサポートされていないと説明されています。
DRPを使っている場合は、計画ルールで置き換えられるかを先に試します。
Q3. MRPを入れれば在庫は最適になりますか
自動で最適になる機能ではありません。
リードタイム・安全在庫・BOMの精度が、計画の質を決めます。
データの整備が先です。
Q4. 製造業以外でも使えますか
複数の拠点を持つ卸・小売にも使い道があります。
複数の拠点を同時に計画し、拠点の間の移動は計画ルールで扱います。
仕入れて売るだけなら、発注点の運用で足りることもあります。
Q5. MRPを使うには、何を有効にしますか
高度な在庫管理とMaterial Requirements Planningなどを有効にします。
ロケーション・複数ロケーション在庫・組立品目・高度なBOM・作業オーダーも前提です。
自社のアカウントで使えるかは、アカウントの担当に聞いてください。
Q6. What-ifの検討はできますか
計画をコピーして条件を変えて比べられます。
計画の定義ごとに、期間・拠点・品目のグループなどを変えられます。
製品の系列ごとに計画を分けることもできます。
Q7. MRPを含む導入の費用はどのくらいですか
導入全体の中身で決まります。
費用を左右するのは、機能範囲・開発（特に外部連携）・社内の体制・ユーザー数の4つです。
ベンチャーネットの支援例では、150万円程度から2億円程度まで幅がありました（5-1）。
まとめ
- Supply Planning（MRP）は、需要に対する供給を計算し、提案を作る機能
- Oracleは、MRPをTime-Phased Planningの後継と位置づけている
- DRPを含むTime-Phased Planningは、公式にサポートされていない
- 差をつけるのは、土台のデータとメッセージを見る決まり
- 「見える化→整理整頓→Fit&Gap」で品目を絞り、小さく始めて広げる
月曜の朝の発注を、担当者の勘からMRPの提案に移す。
その前に、欠品した品目のリードタイムとBOMを1つ開いてみてください。
もう少し詳しく知りたい方へ
MRPを新しく使うか、Time-Phased Planningから移すか。
土台のデータの点検から、ご相談をお受けしています。
- SaaS型クラウドERP NetSuite導入支援（新しく使う方）
- NetSuiteパートナーリプレイス（導入の立て直し・引継ぎ・伴走保守）（使っていて移行を考える方）
- お問い合わせ
