「ERPに寄せれば、営業と販売のツールは1つにまとまる」
そう考えて検討を始めると、すぐに手が止まります。
CRM（顧客・商談の記録を管理する仕組み）、販売管理ソフト、店舗のPOSレジ。
別々の会社の製品に、それぞれ取引先のデータが入っているからです。
NetSuiteとOdooで販売まわりの4業務を比べると、答えは業務ごとに分かれます。
CRMと販売管理は、どちらのERPでも標準で回ります。
店舗のPOSレジは、ERPに寄せず専用のサービスとつなぐのが現実的です。
レンタル管理は、NetSuiteの標準にはありませんが、作れば動きます。
では、「作れば動く」業務は作るべきなのか。
この記事の後半は、この判断に使います。
ベンチャーネットは、NetSuite認定パートナー（Solution Provider）です。
あわせてOdooの導入支援も行っており、どちらか一方に誘導する立場ではありません。
会計まわりの6業務はNetSuiteとOdooの会計・請求・経費にあります。
どちらの製品を選ぶかの総論はOdooとNetSuiteの違いをご覧ください。
📌 この記事で分かること
- 販売まわりの4業務が、NetSuiteでは「標準・拡張・連携」のどれになるか
- 店舗のPOSレジを、なぜERPに寄せないほうがよいのか
- レンタル管理を「作る」とは、具体的に何を作ることか
- 作らずに済ませる3つの道と、作らないほうがよい場合の見分け方
- この領域でOdooのほうが合う会社
この領域で見るべきこと
判定は3つ
判定の定義は、親ハブの記事と同じです。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態を指します。
③連携するとは、相手側の商流や法制度への対応が価値の源泉であり、専用のサービスを残してつなぐ状態のことです。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
販売まわりで新しく出てくるのは「②」
判定が①から外れる理由は3つあります。
深さの差／日本の法制度／商流が外側にある。
この3つは、会計・請求・経費の記事の第3章で扱いました。
会計まわりでは、②はほとんど出てきませんでした。
販売まわりには、レンタル管理という代表例があります。
「標準にないが、作れば動く」。この判断の下し方が、後半の中心です。
4業務の判定表
| 業務（Odooのアプリ） | NetSuiteでの実現 | 判定 | 理由 |
|---|---|---|---|
| CRM（CRM） | 顧客・商談・活動が標準。受注・請求と同じデータベース | ① | 高度な営業自動化を使い込んでいる場合のみ③ |
| 販売管理・見積・受注（Sales） | 見積・受注・出荷・請求の標準機能＋日本商習慣 | ① | NetSuiteの中核。差は深さ |
| POSレジ（Point of Sale） | 日本の店舗運用は外部POSとの連携が現実的 | ③ | レジ・決済端末という現場の仕組みが外側にある |
| レンタル管理（Rental） | 標準にはない。貸出・返却・延滞は作れる | ② | 単機能で、データ構造が単純 |
4業務のうち、2業務は①です。
CRMと販売管理は、NetSuiteの中核にあたります。
Odoo側から見た対応表でも、CRMと販売（Sales）はどちらも「同等」。POSは「一部重なる」です。
CRMと販売は、どちらのERPでも標準で回ります。
差が出るのは、残りの2業務（POSレジ・レンタル管理）のほうです。
CRM・販売管理｜NetSuiteの標準が厚い2業務
CRM｜差は「同じデータベースかどうか」
NetSuiteのCRMは標準機能です。
顧客・商談・活動の記録を、受注や請求と同じデータベースで扱います。
Odooも同じ設計で、1つのデータベースを複数のアプリが共有します。
この点では、2つの製品は同じ方向を向いています。
差が出るのは、営業の自動化をどこまで作り込んでいるかです。
営業プロセスの自動化を業務の中心に据えている会社なら、専用のCRMを残して連携する判断もあります。
- CRMそのものの考え方 → NetSuiteのCRMとは
- 営業活動の可視化と予測 → NetSuite SFAとは
- 専用CRMを残す場合の判断 → NetSuiteとSalesforceは連携すべきか一元化すべきか
販売管理｜NetSuiteの中核
見積・受注・出荷・請求は、NetSuiteの標準機能です。
日本の商習慣に必要な機能も含まれています。
この領域では、深さの差がそのまま出ます。
- 構成が複雑な見積の自動化 → NetSuite CPQとは
- 複数チャネルの受注を1つにまとめる → マルチチャネル受注管理
- 販売の見通しを立てる → NetSuite SFAで実現する販売予測
- 与信と債権の管理 → 卸売・商社のNetSuite活用ガイド
この4本に書かれている範囲は、標準で扱えます。
自社の販売業務がこの範囲に収まるなら、この領域で製品の差は生まれません。
ECサイトやWebサイトは、別の領域です。
Odooとの比べ方はNetSuiteとOdooのマーケティング・Web・EC、EC基盤とのつなぎ方はNetSuite EC連携とはにあります。
POSレジ｜店舗の現場は、外側に置く
判定は③（連携）
店舗のPOSレジは、専用のサービスを残して連携する形が現実的です。
レジ・決済端末・キャッシュレス決済という現場の仕組みが、外側にあるからです。
- レジの操作画面は、店舗スタッフが毎日触るもの。教育のしやすさが、そのまま運用に効く
- 決済端末は、決済事業者とつながっていることに価値がある
- レシートの様式や軽減税率の扱いは、店舗向けサービス側が対応している
ERPの中に同じものを作っても、この3つは手に入りません。
「商流が外側にある」という理由の、典型的な形です。
🌏 店舗向け機能の提供有無は、契約内容と地域によって変わります。導入時に最新の公式情報でご確認ください。
では、何をERPに渡すのか
連携で渡すのは、店舗で確定した売上と在庫の動きです。
| 店舗側（POS） | ERP側（NetSuite） |
|---|---|
| レジ操作・決済・レシート | — |
| 商品マスタの表示 | 商品マスタの管理 |
| 日々の売上の記録 | 売上の計上・会計への反映 |
| 店舗在庫の引き落とし | 全社在庫の管理・補充の判断 |
店舗の現場は店舗側に。数字の管理はERP側に。
この分担が基本になります。
Odoo側の対応表でも、POSは「一部重なる」の分類です。
Odooにも店舗向けアプリはあります。
それでも、日本の店舗運用に要る範囲は国内の店舗向けサービスのほうが厚い、という見立ては同じです。
つなぐ前に決める3つ
- 渡す単位：1件ずつか、1日分をまとめてか
- 渡す頻度：即時か、1日1回か
- 返品・値引きの扱い：店舗側で完結させるか、ERPまで戻すか
漏れやすいのは3つ目です。
返品を店舗側だけで処理すると、ERP側の売上が合わなくなります。
レンタル管理｜「標準にない」を、作るかどうか
判定は②（拡張で補う）
NetSuiteの標準に、レンタル管理の機能はありません。
それでも判定を②にしたのは、作れる形をしているからです。
Odooには専用のレンタルアプリがあります。
Odooが軽い単機能のアプリを持つ領域に、ここは当たります。
「作る」とは、何を作ることか
レンタル管理で記録したいのは、次の3つです。
| 記録すること | 中身 |
|---|---|
| 貸出 | いつ、どの顧客に、どの品目を、いつまで貸したか |
| 返却 | いつ戻ってきたか、状態はどうか |
| 延滞 | 返却期限を過ぎていないか、超過分の請求はいくらか |
これを、貸出の記録を保存する入れ物（レコード）と、期限を見て知らせる仕組み（ワークフロー）で作ります。
あわせて、貸出中の品目が在庫の状態と連動するようにつなぎます。
作り方の土台はNetSuiteのワークフロー機能で扱っています。
作ると、何が手に入るか
作った仕組みは、会計・在庫・顧客と同じデータベースの上で動きます。
- 延滞の超過料金が、そのまま請求につながる
- 貸出中の品目が、在庫の数字に反映される
- 顧客ごとの貸出履歴が、商談の記録と同じ画面から見える
専用のレンタル管理サービスを使うなら、この3つは連携で作ることになります。
作らずに済ませる道も、先に見ておく
②の結論は「作る」です。
ただ、作らない道も3つあります。比べてから決めてください。
| 道 | 向いている場合 | 引き換えに失うもの |
|---|---|---|
| 専用サービスと連携する | その業務が事業の中心にある | 連携の設計と保守が要る |
| 運用でしのぐ（表計算などで管理する） | 件数が少なく、当面増えない | 全社の数字とつながらない |
| その業務をERPに載せない | 業務そのものを見直す余地がある | ——（見直せるなら、これが最も軽い） |
まず件数を数えます。
月に数件なら、作る費用が見合わないことがあります。
②を選ぶ前に決める3つのこと
「作れます」は、答えになっていません。
作ったものを持ち続けられるかどうかが、判定の本当の中身です。
そもそも②になる条件は3つ
親ハブの記事では、②になる条件が3つ挙げられています。
- 単機能でデータ構造が単純
- 法規制の変化が遅い
- 項目・レコード・ワークフローで作れる
レンタル管理は3つとも満たすので、②です。
逆に、給与計算は2つ目を満たしません。
法改正のたびに直し続けることになり、②にはなりません。
自社の「標準にない業務」を、この3つに通してみてください。
1つでも欠けたら、②は現実的ではありません。
そのうえで、3つを決める
3条件を満たしていても、まだ決めることがあります。
| # | 決めること | 決まっていないと |
|---|---|---|
| 1 | 誰が作るか | 見積だけ取って止まる |
| 2 | 誰が直し続けるか | 作った人の異動で止まる |
| 3 | どこまで作るか | 要望が足され続けて終わらない |
いちばん抜けるのは、2つ目です。
業務が変われば、作った仕組みも直す必要があります。
直す人が決まっていないと、数年後には「誰も触れない仕組み」が残ります。
3つ目は、最初に範囲を紙に書きます。
レンタルなら「貸出・返却・延滞の記録まで。予約と配送手配は含まない」といった形です。
作らないほうがよい場合
次の場合、②はお勧めしません。
- その業務が事業の中心にある場合
レンタルが売上の柱なら、専用のレンタル管理サービスのほうが早く、機能も深くなります。作る意味が出るのは、周辺業務のときです - 法規制や商習慣が頻繁に変わる場合
直し続けるコストが、作る費用を上回ります - 社内に直す人がいない場合
外部に頼むこと自体は問題ありません。ただ、保守の体制まで契約に含めていないなら、作らないほうが安全です
作れるかどうかではなく、作ったものを5年持てるかどうかで決めてください。
この領域でOdooが合う会社
販売まわりに限れば、次の条件がそろう会社はOdooのほうが素直です。
- レンタル・予約・アンケートのような、軽い単機能を複数使いたい
- 販売管理は、見積・受注・請求の基本の範囲で足りている
- 営業の自動化を作り込む予定がない
- 小さく始めて、使うアプリを後から足していきたい
Odooは、こうした軽いアプリを最初から持っています。
作る手間がかからない分、立ち上がりが早くなります。
NetSuiteが効いてくるのは、次の場合です。
- 販売の量が多く、複数チャネル・複数倉庫をまたぐ
- 見積の構成が複雑で、価格のルールが多い
- 与信の管理が業務に組み込まれている
- 軽い単機能は1つか2つで、それ以外は標準で足りる
分かれ目は、軽い単機能がいくつ要るかです。
5つ6つと並ぶなら、Odooのほうが合います。
1つか2つなら、作ってNetSuiteに載せるほうが、後の運用は軽くなります。
つまずく3つのパターン
パターン1：POSをERPに寄せようとする
現象
店舗の売上もERPで扱いたいと考え、POSの置き換えを検討する。要件が膨らみ、店舗スタッフの教育まで含めると現実的でなくなる。
構造的な原因
数字の管理と、現場の操作を、1つの問題として扱っているためです。
ERPが担うのは前者です。後者は店舗向けサービスの領域にあります。
回避策
「店舗の現場は店舗側、数字の管理はERP側」と先に線を引きます。
そのうえで、渡す単位・頻度・返品の扱いの3つだけを決めます。
パターン2：「作れます」で発注してしまう
現象
標準にない業務について「作れます」という回答をもらい、そのまま発注した。半年後、作った人が異動し、誰も触れなくなった。
構造的な原因
作る話と、直し続ける話が分かれていないためです。
見積書には作る費用しか載らないので、保守の体制が議題に上がりません。
回避策
発注前に「誰が直し続けるか」を確認します。
社外に頼む場合は、保守まで契約に含めます。
パターン3：軽い単機能を、次々に作り足す
現象
レンタル、予約、アンケートと、標準にない機能を1つずつ作っていった。3年後には自社専用の仕組みが5つ並び、バージョンアップのたびに全部を確認している。
構造的な原因
1つずつの判断が小さいため、合計が見えないまま増えるからです。
1つ目は正しい判断でも、5つ目まで同じとは限りません。
回避策
「作る仕組みは3つまで」といった上限を、先に決めておきます。
上限に達したら、その領域には別の製品のほうが合っている可能性があります。
ベンチャーネットならこう見る｜標準に合わせる／開発する／残す
型1：業務の見える化から始める
製品を比べる前に、ベンチャーネットは販売の業務を書き出します。
いまの流れを現場に聞いて描き、やめる・まとめる・そろえる業務を決める。
そのうえで、残った業務を製品の標準機能と照らし合わせます。
型2：合わない業務は、3つのどれかに決める
照らし合わせて合わなかった業務は、3つのどれかに決めます。
この記事の判定①②③は、この3つにそのまま重なります。
- 標準に合わせる（①）：CRMや販売管理のように、業務のほうを標準機能に寄せる
- 開発する（②）：レンタル管理のように、作れる形のものを作り、直し続ける体制も決める
- 残す（③）：POSレジのように、専用のサービスを残してつなぐ
ベンチャーネットは、①の設計、②の開発と保守、③の連携設計のどれも引き受けます。
②は、作るところから直し続けるところまでです。
③は、渡す単位・頻度・返品の扱いまで含めて設計します。
そのうえで、第6章の「作らないほうがよい場合」に当てはまるときは、作らないことをお勧めします。
軽い単機能が5つ6つ要る会社には、Odooのほうが合うとお伝えします。
今日できること｜4問
販売まわりで、いま使っているサービスを書き出してください。
そのうえで、4つの質問に答えます。
- 標準にない業務はいくつあるか
- その業務は、事業の中心か周辺か
- 作った場合、誰が直し続けるか
- 店舗の売上を、いまどう集計しているか
1が4つ以上なら、Odooのような軽いアプリを持つ製品が合う可能性があります。
2で「中心」なら、専用のサービスを残すほうが早く進みます。
3が決まらないなら、その業務は作らないでください。
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表が使えます。
よくある質問
Q1. NetSuiteにCRMがあるなら、いま使っているCRMは解約すべきですか
使っている機能の範囲で決まります。
顧客・商談・活動の記録が中心なら、NetSuiteの標準に寄せられます。
営業プロセスの自動化を作り込んでいるなら、残して連携する判断もあります。
判断の軸はNetSuiteとSalesforceは連携すべきか一元化すべきかにあります。
Q2. POSレジをNetSuiteに置き換えられませんか
置き換えはお勧めしません。
レジの操作性、決済端末、レシートの様式は、どれも店舗向けサービス側の強みです。
ERPが担うのは、店舗で確定した売上と在庫を、全社の数字につなぐところ。
この分担が、いちばん手戻りが少なくなります。
Q3. レンタル管理は、どれくらいで作れますか
作る範囲で大きく変わります。
貸出・返却・延滞の記録までと、予約・配送手配・保守履歴まででは、規模がまったく違います。
まず「どこまで作るか」を紙に書いてください。
そこが決まれば、見積は短時間で出せます。
Q4. 標準にない業務は、いくつまで作ってよいですか
目安は3つまでです。
4つ目を作る段階は、その領域が本当にNetSuiteに合っているかを見直す時期です。
軽い単機能が5つ6つ要るなら、そうしたアプリを最初から持つ製品のほうが、運用は軽くなります。
Q5. Odooのレンタルアプリと、NetSuiteで作ったものは何が違いますか
できることより持ち方が違います。
Odooは最初から持っているので、すぐ使えます。
そのかわり、自社の運用に合わせる余地は標準の範囲に収まります。
NetSuiteで作れば、自社の運用に合わせられます。そのかわり、作る手間と、直し続ける体制が要ります。
Q6. この記事の判定は、自社にそのまま当てはまりますか
判定の理由のほうを見てください。
この記事の判定は、中堅の製造・卸売・商社を想定した一般的な見立てです。
①から外れる理由（深さの差／日本の法制度／商流が外側）は会計・請求・経費の記事に、②になる条件は第6章にあります。
この2つに自社の状況を通せば、判定は自分で付け直せます。
まとめ：「作れます」は、答えではない
- 販売まわりの4業務のうち、CRMと販売管理はNetSuiteの標準で足りる
- POSレジは③（連携）。レジ・決済端末という現場の仕組みが外側にある
- レンタル管理は②（拡張）。単機能でデータ構造が単純
- ②になる条件は3つ：単機能／法規制の変化が遅い／項目・レコード・ワークフローで作れる
- 3条件を満たしても、誰が作るか・誰が直し続けるか・どこまで作るかが決まるまでは発注しない
- その業務が事業の中心にあるなら、作らないほうがよい
ERPに寄せれば1つにまとまる。
その考えは、CRMと販売管理までは当たっています。
残りの業務は、作れるかではなく、作ったものを5年持てるかで決めてください。
もう少し詳しく知りたい方へ
標準にない業務の一覧を見ながら、作るか・つなぐか・あきらめるかを一緒に決めるところから始められます。
作らないほうがよい場合は、そうお伝えします。
コメント
コメント一覧 （4件）
[…] 販売・CRM・店舗 […]
[…] 販売・CRM・店舗 […]
[…] 販売・CRM・店舗 […]
[…] 販売・CRM・店舗 […]