「在庫管理はできますか」
この質問に、NetSuiteもOdooも「できます」と答えます。製造も購買も同じです。
だから、この領域は比較になりません。
比べるべきなのは、機能があるかどうかではありません。
自社にどこまでの深さが要るのかです。
この記事では、その深さを測る方法を扱います。
会計まわりはNetSuiteとOdooの会計・請求・経費、販売まわりはNetSuiteとOdooの販売・CRM・店舗で扱いました。
先に立場をお伝えします。ベンチャーネットはNetSuite認定パートナー（Solution Provider）であり、あわせてOdooの導入支援も行っています。どちらか一方に誘導する立場ではありません。
📌 この記事で分かること
- 在庫・購買・製造まわりの7業務の判定
- 自社に要る深さを測る4つの目盛り
- 目盛りの読み方——製品で差がつく境目はどこか
- BOMの改訂と設計変更の記録は、どう違うか
- この領域で唯一、Odooのほうが標準で持っている業務
この領域で見るべきこと｜「できます」では決まらない
判定は3つ
親ハブの記事と同じ定義を使います。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態のことです。
③連携するとは、相手側の商流や現場の仕組みが価値の源泉であり、専用のサービスを残してつなぐ状態のことです。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
この領域は、ほとんどが①です
前の2本では、判定が①から外れる場合を扱いました。
- ③になる理由（深さの差／日本の法制度／商流が外側）→ 会計・請求・経費の記事の第3章
- ②になる条件（単機能／法規制の変化が遅い／レコードとWFで作れる）→ 販売・CRM・店舗の記事の第6章
在庫・購買・製造は、ほとんどが①です。両方の製品に機能があります。
だから読者の問いが変わります。
「どの判定か」ではなく、「どこまでの深さが要るのか」です。
7業務の判定表
先に結論を置きます。
| 業務 | Odooのアプリ | NetSuiteでの実現 | 判定 |
|---|---|---|---|
| 在庫管理 | Inventory | 複数拠点・ロット・引当・棚卸が標準 | ① |
| 購買管理 | Purchase | 発注・承認・入荷・照合が標準 | ① |
| 製造管理 | Manufacturing | 製造指図・部品表が標準。工程・実績は追加ライセンス | ① |
| PLM（設計情報） | PLM | 部品表の改訂は標準。本格的なPLMは外側 | ①／③ |
| 品質管理 | Quality | 品質の機能あり（追加ライセンス） | ① |
| 設備保全 | Maintenance | 標準にはない | ②／③ |
| バーコード | Barcode | モバイル・倉庫の機能（追加ライセンス） | ① |
7業務のうち5業務が①です。この領域はNetSuiteの標準がいちばん厚い場所です。
Odoo側から見た対応表では、在庫は「同等」、購買と製造は「一部重なる」と整理されています。
大きく違うのは1業務だけで、それが設備保全です（第6章）。
🌏 製造・品質・バーコードは追加のライセンスが必要になる場合があります。範囲は契約内容によって変わるため、導入時に最新の公式情報でご確認ください。
深さを測る4つの目盛り
ここが本記事の核です。
両方の製品に機能があるので、「ある・ない」では決まりません。
かわりに、自社の業務がどれだけ深いかを測ります。
目盛りは4つです。
追跡の単位
| 浅い側 | 深い側 |
|---|---|
| 品目ごとに、いくつあるかが分かればよい | ロット・シリアル単位まで追う |
どの製造ロットが、どの取引先に、いつ出荷されたか。
食品・医薬・電子部品のように、後から遡る必要がある業界では深い側になります。
追跡そのものの仕組みはロット・シリアル管理で扱っています。
置き場所の数
| 浅い側 | 深い側 |
|---|---|
| 在庫の置き場所が1か所 | 複数の倉庫・拠点をまたぐ |
拠点が増えると、どこに何があるかに加えて、どこから出すかを決める必要が出ます。
倉庫の中の棚単位まで管理するなら、さらに深い側です。
倉庫内の管理はNetSuite WMSとは、現場の読み取りはバーコード運用と外部ハンディとの連携で整理しています。
作り方
| 浅い側 | 深い側 |
|---|---|
| 作り置きして、売れた分を補充する | 受注のたびに仕様が変わる／工程ごとに実績を取る |
同じものを繰り返し作るなら、必要な機能は少なくて済みます。
案件ごとに仕様が変わる場合や、工程ごとの進捗を見る場合は深い側です。
部品表そのものはBOM（部品表）とは、必要量の計算は所要量計画（MRP）、工程の管理はNetSuite Advanced Manufacturingで扱っています。
原価の出し方
| 浅い側 | 深い側 |
|---|---|
| 月末にまとめて計算する | 製造指図ごと・工程ごとに出す |
原価をいつ・どの単位で知りたいかは、必要な深さを大きく左右します。
月次でよいなら、仕組みは軽くて済みます。指図ごとに知りたいなら、工程の実績が要ります。
原価計算の方式は個別原価計算と総合原価計算で整理しています。
目盛りの読み方｜深い側がいくつあるか
4つの目盛りのうち、深い側がいくつあるかを数えてください。
| 深い側の数 | 見立て |
|---|---|
| 0〜1個 | この領域では、製品で差がつきません。判断材料になりません |
| 2〜3個 | 差が出始めます。どの目盛りが深いかで、必要な機能が変わります |
| 4個すべて | 深さがそのまま導入の理由になります |
0〜1個なら、この領域では決まりません
品目ごとの数が分かればよく、置き場所も1か所。作り置きで、原価は月末にまとめて出す。
この状態なら、在庫・購買・製造の機能で製品を選ぶ理由はありません。
会計や販売など、他の領域で判断してください。
「在庫管理ができます」という説明は、この場合、判断材料になっていません。
2〜3個なら、深い目盛りだけを見る
たとえば、ロット追跡が要って、倉庫が3拠点ある。でも作り置きで、原価は月末まとめ。
この場合、確かめるべきは追跡と拠点の2つだけです。
工程管理や指図別原価の機能があるかどうかは、判断に関係ありません。
深い目盛りだけを比較の対象にしてください。全機能を並べた比較表は、判断を遅くします。
4個すべてなら、深さが導入理由になります
ロットまで追い、複数拠点をまたぎ、個別受注で作り、指図ごとに原価を出す。
ここまで来ると、標準でどこまで持っているかがそのまま差になります。
NetSuiteは、この範囲を最初から設計に含んでいます。積み上げて到達するのではなく、はじめから一体で持っている形です。
製造業でのERP選定の考え方は製造業のERP選定、NetSuiteの製造機能はNetSuiteの製造管理で扱っています。
当ててみると、こう分かれます
説明のための例を2つ挙げます。特定の会社のものではありません。
| 目盛り | 例A：日用品の卸 | 例B：食品の製造 |
|---|---|---|
| 追跡の単位 | 品目ごと | ロットまで |
| 置き場所の数 | 2拠点 | 3拠点＋外部倉庫 |
| 作り方 | 仕入のみ（製造なし） | 作り置き＋一部受注生産 |
| 原価の出し方 | 月末にまとめて | 製造指図ごと |
| 深い側の数 | 1個 | 4個 |
例Aは深い側が1個です。在庫の機能で製品を選ぶ理由がありません。
見るべきは拠点間の在庫移動が扱えるかどうかだけで、これはどちらの製品にもあります。判断は会計や販売の領域に移ります。
例Bは4個すべてです。標準でどこまで持っているかが、そのまま差になります。
ロット追跡・複数拠点・工程実績・指図別原価を、後から足すのか最初から持っているのかで、導入の重さが変わります。
同じ「在庫管理をしたい」でも、必要なものはここまで違います。
PLM｜BOMの改訂と、設計変更の記録は別
この領域で、線引きが分かりにくいのがPLMです。
PLMとは、製品の設計情報とその変更の履歴を管理する仕組みのことです。
3つに分けて考えてください。
| やりたいこと | 判定 | 実現方法 |
|---|---|---|
| 部品表を改訂し、どの版を使うか管理する | ① | 標準のBOM改訂機能 |
| 設計変更の申請・承認・適用日を記録する | ② | 記録の入れ物と承認の流れを作る |
| 図面・仕様書・変更履歴を版ごとに一元管理する | ③ | 設計情報を扱う専用サービスと連携する |
多くの会社は①で足ります。部品表の版が管理できれば、製造の現場は回ります。
②に進むのは、「いつからこの変更を適用するか」を記録として残したい場合です。
承認の流れは標準のワークフローで作れます。作った記録は、部品表や製造指図と同じデータベースの上に載ります。
③が要るのは、設計部門が図面そのものを資産として扱う場合です。ここはERPの外側です。
部品表そのものの考え方はBOM（部品表）とはにまとめています。
設備保全｜この領域で唯一、Odooのほうが標準で持っている
正直に書きます。
NetSuiteの標準に、設備保全の機能はありません。
一方、Odooには保全のアプリがあります。
親ハブの2つの資料を突き合わせた結果、在庫・購買・製造の7業務のうち、Odoo側が標準で持ち、NetSuite側が持たないのは、この設備保全だけでした。
NetSuiteでどうするか
2つの道があります。
| 道 | 向いている場合 |
|---|---|
| ②作る | 設備台帳と定期点検の記録まででよい。件数が多くない |
| ③連携する | 保全が事業の中心にある。作業指示・部品在庫・稼働履歴まで扱う |
②で作るのは、設備の台帳と、点検の予定・実績の記録です。
点検日が近づいたら知らせる仕組みは、標準のワークフローで作れます。
作るかどうかの決め方は、販売・CRM・店舗の記事の第6章にまとめた3条件と3つの決めごとをそのまま使ってください。
なお、自社の設備ではなく顧客先での保守作業を扱う場合は、別の機能の領域になります。フィールドサービス管理で扱っています。
なぜ、この事実を先に書くのか
設備保全が業務の中心にある会社に、NetSuiteをお勧めすることはありません。
比較の途中でこれを伏せておくと、導入後に分かります。
先に言っておくほうが、双方にとって早いからです。
この領域でOdooが合う会社
引き続き、正直に書きます。
在庫・購買・製造に限れば、次の条件がそろう会社はOdooのほうが素直です。
- 第3章の目盛りで、深い側が0〜1個
- 設備保全を業務の中心に置いている
- 在庫の置き場所が1か所か2か所
- 作り置きが中心で、原価は月末にまとめて出している
- 小さく始めて、使うアプリを後から足していきたい
この条件では、NetSuiteの標準が厚いことが利点になりません。使わない深さに費用を払うことになります。
逆に、NetSuiteが効いてくるのは次の場合です。
- 第3章の目盛りで、深い側が2個以上
- ロット・シリアルまで追う必要がある
- 複数の倉庫・拠点をまたいで在庫を動かす
- 工程ごとの実績と、指図ごとの原価が要る
目盛りの数が、そのまま分かれ目になります。
つまずく3つのパターン
パターン1：全機能を並べた比較表で選ぶ
現象
在庫・購買・製造の機能を数十行の表にして比べる。どちらも丸ばかりで差がつかず、最後は価格で決める。
構造的な原因
自社に要る深さを先に決めていないためです。深さが決まっていないと、使わない機能まで比較の対象になります。
回避策
第3章の4つの目盛りを先に当ててください。深い側が2個なら、確かめるのはその2つだけです。表は数行で足ります。
パターン2：「将来必要になるかもしれない」で深さを足す
現象
いまは作り置きだが、将来は個別受注もやるかもしれない。そう考えて、工程管理まで含めた構成で見積を取る。
構造的な原因
将来の可能性を、現在の要件として扱っているためです。使わない機能の費用と、設定・教育の手間が最初から乗ります。
回避策
「3年以内に確実に起きること」だけを要件にしてください。それ以外は、後から足せるかどうかだけ確認すれば足ります。
パターン3：現場の読み取り手段を最後に考える
現象
在庫の仕組みを決めた後で、現場のバーコード読み取りをどうするか検討する。既存のハンディ端末が使えず、運用が回らない。
構造的な原因
画面の設計と、現場の入力手段が別の議題になっているためです。入力が止まると、どれだけ良い設計でも数字が合わなくなります。
回避策
在庫の設計と同時に、現場が何を使って入力するかを決めてください。既存端末を使う場合は外部ハンディとの連携を、新しく揃える場合はバーコード運用を先に確認します。
ベンチャーネットの対応
ベンチャーネットは、NetSuite認定パートナー（Solution Provider）であり、あわせてOdooの導入支援も行っています。
SAP・NetSuite・Odoo・AIスクラッチ開発を扱い、特定の製品に誘導しない立場を取っています。
この領域では、次の3つを引き受けます。
- 深さの見極め：4つの目盛りを一緒に当て、要る深さと要らない深さを分けます
- ②の開発と保守：設計変更の記録、軽い検査記録、設備台帳など、標準にない部分を作り、直し続けます
- ③の連携設計：倉庫サービス、生産管理パッケージ、保全サービスとの接続を設計・実装します
そして、深い側が0〜1個の会社には、この領域を判断材料にしないようお伝えします。
設備保全が事業の中心にある会社には、Odooを含めた選択肢をお伝えします。
今日できること｜4つの目盛りを当てる
紙に4つの目盛りを書き、自社がどちら側かを丸で囲んでください。
- 追跡の単位：品目ごと ／ ロット・シリアルまで
- 置き場所の数：1か所 ／ 複数の倉庫・拠点
- 作り方：作り置き ／ 個別受注・工程ごとの実績
- 原価の出し方：月末にまとめて ／ 指図ごと・工程ごと
右側（深い側）がいくつあるかを数えます。
- 0〜1個：この領域では製品が決まりません。他の領域で判断してください
- 2〜3個：右側になった目盛りだけを、比較の対象にしてください
- 4個：深さがそのまま導入の理由になります
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表を使ってください。
もう少し詳しく知りたい方へ
4つの目盛りを当てた結果を持ってご相談いただければ、そこから先の切り分けは短時間で済みます。
深い側が0〜1個の場合は、そうお伝えします。
よくある質問
Q1. 在庫管理は、どちらの製品でもできるのですよね
どちらもできます。だから比較になりません。
差が出るのは、追跡の単位・置き場所の数・作り方・原価の出し方という深さの部分です。
自社がどこまで深いかを先に測ってください。深い側が0〜1個なら、この領域は判断材料になりません。
Q2. 設備保全がNetSuiteの標準にないのは、弱点ですか
この領域で唯一、Odooのほうが標準で持っている業務です。そのままお伝えしています。
NetSuiteでは、設備台帳と点検の記録までなら作れます。保全が事業の中心にあるなら、専用のサービスを残すか、Odooを含めて検討するほうが現実的です。
Q3. PLMがないと、設計変更は管理できませんか
部品表の改訂は標準でできます。
「いつからこの変更を適用するか」という申請と承認の記録を残したいなら、それは作れる範囲です。
図面そのものを版ごとに管理するなら、ERPの外側になります。3つの線引きは第5章にまとめました。
Q4. 追加ライセンスが必要な機能は、どれですか
製造の工程管理、品質管理、バーコードの機能は、追加のライセンスが必要になる場合があります。
範囲は契約内容によって変わるため、導入時に最新の公式情報でご確認ください。
本記事では、どの機能に費用がかかるかではなく、その深さが自社に要るかを先に決めることをお勧めしています。
Q5. いまの生産管理パッケージを残したまま、NetSuiteを入れられますか
できます。ただし、どちらが在庫の数字を持つかを先に決めてください。
両方が在庫を持つと、必ず食い違います。生産の実績はパッケージ側、在庫と原価はERP側、というように持ち場を分けるのが基本です。
Q6. この記事の判定は、自社にそのまま当てはまりますか
判定より、第3章の目盛りを使ってください。
本記事の判定は、中堅の製造・卸売・商社を想定した一般的な見立てです。
4つの目盛りに自社を当てれば、必要な深さは自分で測れます。その数が、この領域での答えになります。
まとめ：比べるのは機能ではなく、深さ
この記事の要点を整理します。
- 在庫・購買・製造の7業務のうち、5業務はNetSuiteの標準で足ります
- どちらの製品も「できます」と答えるため、機能の有無では決まりません
- 測るのは4つ。追跡の単位／置き場所の数／作り方／原価の出し方
- 深い側が0〜1個なら、この領域では製品が決まりません
- 深い側が2個以上なら、その目盛りだけを比較の対象にしてください
- 設備保全は、この領域で唯一Odooのほうが標準で持っています
「在庫管理ができます」という説明は、判断材料になっていません。
自社に要る深さを先に測れば、比較する項目は数行に減ります。
紙に4つの目盛りを書くところから、一緒に始めましょう。
