在庫・購買・製造まわりの7つの業務を、NetSuiteとOdooで並べてみます。
7つのうち5つは、NetSuiteの標準で足ります。
Odooにも、7つすべてにアプリがあります。
はっきり差が出るのは、1つだけです。
「在庫管理はできますか」と聞けば、どちらも「できます」と答えます。
製造も購買も同じです。
だから、この領域は機能の有無では比べられません。
比べるべきなのは、自社にどこまでの深さが要るのかです。
深さは、4つの目盛りで測れます。
では、目盛りがいくつ深い側に振れたら、製品で差がつくのか。
ベンチャーネットは、NetSuite認定パートナー（Solution Provider）です。
あわせてOdooの導入支援も行っており、どちらか一方に誘導する立場ではありません。
会計まわりはNetSuiteとOdooの会計・請求・経費、販売まわりはNetSuiteとOdooの販売・CRM・店舗にあります。
📌 この記事で分かること
- 在庫・購買・製造まわりの7業務の判定
- 自社に要る深さを測る4つの目盛り
- 目盛りの読み方と、製品で差がつく境目
- BOMの改訂と設計変更の記録は、どう違うか
- この領域で唯一、Odooのほうが標準で持っている業務
この領域で見るべきこと｜「できます」では決まらない
判定は3つ
判定の定義は、親ハブの記事と同じです。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態を指します。
③連携するとは、相手側の商流や法制度への対応が価値の源泉であり、専用のサービスを残してつなぐ状態のことです。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
この領域は、ほとんどが①
前の2本では、判定が①から外れる場合を扱いました。
- ③になる理由（深さの差／日本の法制度／商流が外側）→ 会計・請求・経費の記事の第3章
- ②になる条件（単機能／法規制の変化が遅い／レコードとワークフローで作れる）→ 販売・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：現場の読み取り手段を最後に考える
起きること：在庫の仕組みを決めた後で、現場のバーコード読み取りを検討する。既存のハンディ端末が使えず、運用が回らない。
原因：画面の設計と現場の入力手段が別の議題になっている。
入力が止まれば、どれだけ良い設計でも数字は合わなくなります。
避け方：在庫の設計と同時に、現場が何で入力するかを決めてください。
既存端末を使うなら外部ハンディとの連携、新しくそろえるならバーコード運用を先に読んでおきます。
ベンチャーネットならこう見る｜深さを測ってから、3つに分ける
「機能の一覧で比べれば、差が見えるはずだ」
この領域では、その期待は外れます。
どちらも丸が並ぶからです。
型1：見える化→整理整頓→Fit&Gap
ベンチャーネットは、製品を比べる前に、業務の見える化から始めます。
いまの在庫の置き場所、追跡の単位、作り方、原価の出し方を、現場に聞いて描きます。
4つの目盛りは、この見える化の結果を読むための物差しです。
整理整頓の段で、「将来要るかもしれない」深さを外します。
残った深い目盛りだけを、候補の製品の標準機能と照らし合わせます。
型2：標準に合わせる／開発する／残す
照らし合わせて合わなかった業務は、3つのどれかに決めます。
この記事の判定①②③は、この3つにそのまま重なります。
- 標準に合わせる（①）：在庫・購買・製造の多くは、NetSuiteの標準に業務を寄せる
- 開発する（②）：設計変更の記録、軽い検査記録、設備台帳など、標準にない部分を作り、直し続ける
- 残す（③）：倉庫サービス、生産管理パッケージ、保全サービスを残し、接続を設計・実装する
ベンチャーネットは、①の見極め、②の開発と保守、③の連携設計のどれも引き受けます。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
そのうえで、深い側が0〜1個の会社には、この領域を判断材料にしないようお伝えします。
設備保全が事業の中心にある会社には、Odooを含めた選択肢をお伝えします。
今日できること｜4つの目盛りを当てる
紙に4つの目盛りを書き、自社がどちら側かを丸で囲んでください。
- 追跡の単位：品目ごと ／ ロット・シリアルまで
- 置き場所の数：1か所 ／ 複数の倉庫・拠点
- 作り方：作り置き ／ 個別受注・工程ごとの実績
- 原価の出し方：月末にまとめて ／ 指図ごと・工程ごと
右側（深い側）がいくつあるかを数えます。
- 0〜1個：この領域では製品が決まらない。ほかの領域で判断する
- 2〜3個：右側になった目盛りだけを、比較の対象にする
- 4個：深さがそのまま導入の理由になる
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表を使ってください。
よくある質問
Q1. 在庫管理は、どちらの製品でもできるのですよね
どちらもできます。
だから、機能の有無では比べられません。
差が出るのは深さです。追跡の単位、置き場所の数、作り方、原価の出し方の4つで測ります。
深い側が0〜1個なら、この領域は判断材料になりません（第3章・第4章）。
Q2. 設備保全がNetSuiteの標準にないのは、弱点ですか
この領域で唯一Odooのほうが標準で持っている業務です。
NetSuiteでは、設備台帳と点検の記録までなら作れます。
保全が事業の中心にあるなら、専用のサービスを残すか、Odooを含めて検討するほうが現実的です（第6章）。
Q3. PLMがないと、設計変更は管理できませんか
部品表の改訂は標準でできます。
「いつからこの変更を適用するか」の申請と承認の記録は、作れる範囲です。
図面そのものを版ごとに管理するなら、ERPの外側になります（第5章）。
Q4. 追加ライセンスが必要な機能は、どれですか
製造の工程管理と品質管理とバーコードの機能です。
いずれも、追加のライセンスが必要になる場合があります。
範囲は契約内容によって変わるため、導入時に最新の公式情報でご確認ください。
費用の前に、その深さが自社に要るかを決めることをお勧めします（第2章）。
Q5. いまの生産管理パッケージを残したまま、NetSuiteを入れられますか
できます。
ただし、どちらが在庫の数字を持つかを先に決めてください。
両方が在庫を持つと、必ず食い違います。
生産の実績はパッケージ側、在庫と原価はERP側、と持ち場を分けるのが基本です（第9章）。
Q6. この記事の判定は、自社にそのまま当てはまりますか
判定より第3章の目盛りを使ってください。
本記事の判定は、中堅の製造・卸売・商社を想定した一般的な見立てです。
4つの目盛りに自社を当てれば、要る深さは自分で測れます。
その数が、この領域での答えになります。
まとめ：比べるのは機能ではなく、深さ
- 在庫・購買・製造の7業務のうち、5業務はNetSuiteの標準で足りる
- どちらの製品も「できます」と答えるため、機能の有無では決まらない
- 測るのは4つ。追跡の単位／置き場所の数／作り方／原価の出し方
- 深い側が0〜1個なら、この領域では製品が決まらない
- 深い側が2個以上なら、その目盛りだけを比較の対象にする
- 設備保全は、この領域で唯一Odooのほうが標準で持っている
7つのうち差がはっきり出るのは1つだけ、と冒頭に書きました。
残りの6つで差をつけるのは、製品ではなく、自社の目盛りです。
紙に4つの目盛りを書くところから始めてください。
もう少し詳しく知りたい方へ
4つの目盛りを当てた結果を持ってご相談いただければ、そこから先の切り分けは短時間で済みます。
深い側が0〜1個の場合は、そうお伝えします。
コメント
コメント一覧 （1件）
[…] 在庫・購買・製造 […]