「メール配信もECも、ERPの中でできるなら、まとめたほうが楽ですよね」
販売や会計を比べ終えた方から、よく出てくる質問です。
マーケ・Web・ECの7業務とは、メール配信・MA・SNS管理・Webサイト・EC・イベント・アンケートのことです。
この領域は、NetSuiteにもOdooにも機能があります。
ただし、専用のサービスのほうが深い領域です。
だから、問うべきは「できるか」ではありません。
どこまで寄せるかです。
では、その線はどこに引けばよいのか。
物差しは1つで足ります。そのデータが、お金からどれだけ離れているかです。
会計まわりは会計・請求・経費、販売まわりは販売・CRM・店舗、在庫まわりは在庫・購買・製造、人事まわりは人事・勤怠・給与で扱いました。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、あわせてOdooの導入支援も行っています。
どちらか一方に誘導する立場ではありません。
📌 この記事で分かること
- マーケティング・Web・ECの7業務が、それぞれ①②③のどれになるか
- ERPに寄せる範囲を決める物差し「お金からの距離」
- 寄せない業務から、何をERPに戻せばよいか
- ECは、なぜ「売り方」で結論が分かれるのか
- この領域が、製品選びの材料になる場合とならない場合
この領域で見ること｜できるかより、どこまで寄せるか
判定は3つ
判定の言葉は、親ハブの記事と同じ定義です。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態を指します。
③連携するは、相手側の商流や法制度への対応が価値の源泉であり、専用のサービスを残してつなぐ状態です。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
ここまでの4本と、問いが変わる
| 記事 | 読者の問い |
|---|---|
| 会計・請求・経費 | 残すか、寄せるか（③になる理由） |
| 販売・CRM・店舗 | 作るか、あきらめるか（②になる条件） |
| 在庫・購買・製造 | どこまでの深さが要るか |
| 人事・勤怠・給与 | そもそも比べる必要があるか |
| 本記事 | ERPにどこまで寄せるか |
在庫・購買・製造は、ERPの標準がいちばん厚い領域でした。
マーケティング・Web・ECは、その逆です。
ERPにも機能はありますが、専用のサービスのほうが深く、進化も速い。
そのため「ERPでできるか」と問うと、たいてい「できる」と返ってきます。
決めるべきなのは、できる範囲のうち、どこまでを寄せるかです。
7業務の判定表
親ハブの対応表と、Odoo側の対応表を並べます。
| 業務（Odooのアプリ） | NetSuiteでの実現 | NetSuite側の判定 | Odoo側の関係 |
|---|---|---|---|
| メール配信（Email Marketing） | CRMのキャンペーン機能で簡易な配信は可能。規模と到達性は専用サービス | ①／③ | 同等 |
| MA（Marketing Automation） | 本格的なMAは標準にない | ③ | 一部重なる |
| SNS管理（Social Marketing） | 標準にはない | ③ | — |
| Webサイト（Website） | EC・サイトの機能はあるが、コーポレートサイトの用途には不向き | ③ | 一部重なる |
| EC（eCommerce） | ECの機能（追加ライセンス）。既存ECとの連携が一般的 | ①／③ | 一部重なる |
| イベント（Events） | 簡易なイベント管理は拡張で作れる。申込・決済は連携 | ②／③ | 一部重なる |
| アンケート（Surveys） | 標準にはない。回答を顧客に紐づける簡易な仕組みは拡張で作れる | ② | 同等 |
MA（マーケティングオートメーション）とは、見込み客への連絡や情報提供を、行動に応じて自動で行う仕組みのことです。
NetSuite側は、③が多く並びます。
Odoo側も「同等」は2つだけ。SNS管理（対応表に行なし）を除く残りは「一部重なる」です。
Odoo側の対応表は第6章で、専用のサービスが業務の中心になっている場合は残して連携する、としています。
どちらの製品から見ても、専用のサービスを残す場面が多い領域です。
寄せる範囲の決め方｜お金からの距離
この領域のデータは、お金に近いものから遠いものまで幅があります。
お金に近いデータほどERPに寄せ、遠いデータほど専用のサービスに任せます。
冒頭の問いへの答えは、この物差しです。
3つの層
| 層 | どんなデータか | 例 | 置き場所 |
|---|---|---|---|
| 第1層：お金と在庫が動く | 受注・出荷・請求・入金に直結する | ECの注文、イベントの有料申込の売上 | ERPに寄せる |
| 第2層：顧客が誰かが決まる | 見込み客が、取引先・顧客になる | 問い合わせ、資料請求、申込者、回答者 | つないでERPの顧客に戻す |
| 第3層：反応を測る | 見られた・開かれた・押された | メールの開封、サイトの閲覧、SNSの反応 | 専用のサービスに任せる |
3つの層は、AIの使いやすさとも重なります。
| 層 | AIとの親和性 | 理由 |
|---|---|---|
| 第1層 | 高い | 注文と在庫がERPの1か所にあれば、売上の要約や傾向の下書きをAIに任せやすい |
| 第2層 | 中くらい | 顧客が2つの仕組みで別人になっていると、AIも同じ顧客として扱えない |
| 第3層 | 専用のサービス側で高い | 反応の分析は、専用のサービスが備えるAIの機能に任せるほうが早い |
第1層は、ERPに寄せる
注文が入れば、在庫が引き当てられ、出荷され、請求され、入金されます。
この流れが途中で別の仕組みに分かれると、転記と照合が生まれます。
店の画面は、専用のサービスに置いても構いません。
ただし、注文が入った瞬間から先はERPの流れに乗せます。
第2層は、つないで戻す
見込み客の情報は、はじめはマーケティングの仕組みの中にあります。
それが商談になり、取引になった時点で、ERPの顧客になります。
ここで避けたいのは、同じ会社・同じ人が、2つの仕組みで別人になることです。
問い合わせをくれた人と、後で注文をくれた人が同じだと分かれば、どの施策が売上につながったかが見えます。
第3層は、専用のサービスに任せる
メールの開封率、ページの閲覧数、SNSの反応。
量が多く、細かく、変化も速いデータです。
ERPに入れても、会計や在庫の判断には使いません。
専用のサービスで分析し、必要なら結果の要約だけを経営の資料に載せれば足ります。
物差しが「お金からの距離」である理由
在庫・購買・製造の記事では、「深さが自社に要るか」を測りました。
この領域では、深さはたいてい専用のサービスのほうにあります。
深さで測ると、すべてが専用のサービスに流れます。
すると、注文や顧客の情報まで外に出て、ERPの中の数字とつながらなくなります。
お金からの距離で測れば、深さは専用のサービスに任せられます。
それでいて、お金に関わる部分だけはERPに残せます。
7業務を3つの層に置くと
第2章の7業務を、3つの層に置いてみます。
| 業務 | 主な層 | ERPに寄せるもの | 専用のサービスに任せるもの |
|---|---|---|---|
| EC | 第1層 | 注文・在庫・出荷・請求・入金 | 店の画面・集客・決済の手段 |
| イベント | 第1層／第2層 | 有料の申込の売上、申込者の顧客情報 | 告知・申込の受付画面・当日の運営 |
| アンケート | 第2層 | 回答と、回答した顧客の紐づけ | 質問の設計・配信 |
| メール配信 | 第2層／第3層 | 配信先の顧客情報 | 配信・開封の計測・到達性の管理 |
| MA | 第2層／第3層 | 商談になった見込み客 | 行動の記録・自動の連絡・点数づけ |
| Webサイト | 第3層 | 問い合わせの内容 | サイトそのもの・閲覧の分析 |
| SNS管理 | 第3層 | （原則なし） | 投稿・反応の分析 |
どの業務も、ERPに寄せるのは一部だけ。
そして寄せる部分は、どれも「注文」か「顧客」のどちらかです。
イベントとアンケートは、作る余地がある
イベントとアンケートは、親ハブで②（拡張で補う）とされています。
- イベント：申込を記録し、見込み客や顧客に紐づける簡易な仕組みは作れる
- アンケート：回答を顧客に紐づける簡易な仕組みは作れる
どちらも、第2層の「顧客が誰か」を残すための仕組みです。
告知や集客まで作り込む必要はありません。そこは専用のサービスのほうが深いからです。
作るかどうかは、販売・CRM・店舗の記事の「②になる条件」に当てはめて決めます。
ECは「売り方」で結論が分かれる
7業務のうち、ECだけは第1層の比重が大きく、判断が重くなります。
そして、どう売るかで結論が変わります。
売り方ごとの分かれ方を図にすると、次のとおりです。
| 売り方 | 考え方 | 詳しい記事 |
|---|---|---|
| 自社ブランドの直販、取引先向けの受発注 | ERPと一体のEC（NetSuiteではSuiteCommerce）が候補になる | SuiteCommerceとは |
| 国内のモールが売上の中心 | 外部のECとつなぎ、注文を一元化する | NetSuiteのEC連携 |
| 既存のカート（Shopifyなど）で売る | カートとERPをつなぐ | Shopify×NetSuite連携の方法 |
公開中のSuiteCommerceの記事では、日本の多くの会社の組み合わせを、自社サイトはERPと一体、モールは外部との接続、と整理しています。
Odoo側の対応表も、ECを「一部重なる」としています。
決済・配送・アプリの広さで、専用のプラットフォームが先行しているためです。
大規模なECを業務の中心にしている会社は、残す判断が現実的だとしています。
どちらの製品でも、ECの画面をどこに置くかより、注文をどこに集めるかが先です。
注文が集まる場所は、第1層の考え方どおりERPです。
戻すデータの設計で決める3つのこと
専用のサービスを残すと決めたら、次の3つを先に決めます。
| # | 決めること | 決まっていないと |
|---|---|---|
| 1 | 顧客をどちらで作るか | 同じ会社がERPとマーケティングの仕組みで別々に登録され、重複する |
| 2 | 何をERPに戻すか | 開封や閲覧まで戻そうとして、連携が重くなる |
| 3 | いつ戻すか | 商談になった見込み客が、ERPに現れるのが遅れる |
戻すのは、層の境目を越えたときだけ
2つ目の「何を戻すか」は、第3章の層で決まります。
- 第3層から第2層に上がったとき（問い合わせ、申込、回答）に、顧客の候補として戻す
- 第2層から第1層に上がったとき（注文、有料の申込）に、取引として戻す
層を上がらないデータは、戻しません。
開封や閲覧は、何度起きても第3層のままです。
逆向きに渡すものもある
ERPから専用のサービスへ渡すものもあります。
たとえば、すでに取引のある顧客かどうか。
これが分かれば、既存の顧客に新規向けの案内を送るような、ちぐはぐな連絡を避けられます。
渡すのは「取引の有無」程度で足ります。
請求の金額まで渡す必要はありません。
この領域が製品選びの材料になる場合、ならない場合
正直に書きます。
マーケティング・Web・ECの領域だけで、NetSuiteとOdooのどちらかを選ぶ理由は、多くの場合立ちません。
どちらの製品でも、深い部分は専用のサービスに任せることが多いからです。
ただし、材料になる場合が2つあります。
小さく、1つの仕組みで始めたい場合
Odooは、Webサイト・EC・メール配信を、同じデータベースの上のアプリとして持っています。
専用のサービスを増やさず、1つの仕組みで小さく始めたい会社には、この形が軽く感じられるはずです。
注文以降の流れが重い場合
複数の拠点や子会社、複数の販路の注文を、在庫・会計と一体で扱う必要がある場合です。
決め手はECの画面ではなく、注文から先の深さになります。
それは在庫・購買・製造や会計・請求・経費の領域で決まる話です。
どちらでもないなら、他の領域で決める
どちらにも当てはまらないなら、この領域は製品を決める材料にしないでください。
製品が決まった後に、第3章の層に沿って寄せる範囲を設計すれば十分です。
つまずく3つのパターン
3つのパターンを、先に図で示します。
パターン1：「ERPでもできる」を理由に、すべて寄せる
現象
メール配信もアンケートも、ERPの中で始める。
配信の規模が大きくなって、到達性や分析の不足に気づき、専用のサービスを追加で入れる。
結局、2つの仕組みで同じ顧客を管理することになる。
構造的な原因
「できるか」だけで判断し寄せる範囲を決めていないためです。
この領域は、ERPの機能が入口として使える一方、深さは専用のサービスにあります。
回避策
第3章の3つの層で、業務ごとに寄せる範囲を先に決めてください。
第3層の業務は、最初から専用のサービスに任せる前提で設計します。
パターン2：すべて外に出し、注文と顧客までERPから離れる
現象
EC・メール・イベントを、すべて専用のサービスで運用する。
注文と顧客の情報がそれぞれに散らばり、どの施策が売上につながったか分からない。
構造的な原因
深さの物差しだけで判断したためです。
深さで測ると、この領域はすべて専用のサービスに流れます。
回避策
第1層（注文）と第2層（顧客）は、必ずERPに戻す設計にします。
画面は外でも、注文と顧客の置き場所はERPです。
パターン3：開封や閲覧まで、ERPに戻そうとする
現象
「データはすべてERPに集めるべきだ」と考え、メールの開封やページの閲覧まで連携する。
連携の量が増え、止まったときの影響も大きくなる。
構造的な原因
一元化をすべてのデータを1か所に置くことだと考えているためです。
会計や在庫の判断に使わないデータまで集めても、判断は速くなりません。
回避策
6-1のとおり、層の境目を越えたときだけ戻すと決めてください。
第3層のデータは、専用のサービスで見れば十分です。
ベンチャーネットならこう見る｜3つの層は「標準に合わせる／開発する／残す」
ベンチャーネットは、標準で収まらない業務を「標準に合わせる／開発する／残す」の3つから選びます。
この領域では、3つの層がそのまま3つの選択に重なります。
| 層 | 選択 | この領域でやること |
|---|---|---|
| 第1層：お金と在庫 | 標準に合わせる | 注文から入金までを、ERPの標準の流れに乗せる |
| 第2層：顧客 | 開発する | 申込や回答を顧客に紐づける仕組み、戻す連携を作る |
| 第3層：反応 | 残す | 専用のサービスを残し、つなぎ方だけ決める |
ただし、選ぶのは業務の見える化のあとです。
いま使っているECやマーケティングの仕組みと、そこから手で転記している数字を先に書き出します。
転記が多い業務ほど、第1層か第2層に置くべきものが外に出ています。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているのがベンチャーネットです。
仕事は、ゼロからの導入より、他社のあとの引き継ぎや他システムとの連携が多くを占めます。
この領域でも、ECや専用のサービスとの接続の設計・実装と、申込・回答を顧客に紐づける仕組みの開発を引き受けます。
そして、この領域だけで製品を決めないよう、はっきりお伝えします。
決め手になるのは、多くの場合、注文から先の深さです。
今日できること｜7業務を3つの層に置く
いま使っている、またはこれから使いたいマーケティング・Web・ECの仕組みを書き出してください。
そして、それぞれが扱うデータを3つの層に置きます。
- 第1層：お金と在庫が動くか（注文・申込の売上）
- 第2層：顧客が誰かが決まるか（問い合わせ・申込者・回答者）
- 第3層：反応を測るだけか（開封・閲覧・SNSの反応）
第1層と第2層に置いたものが、ERPに寄せる、または戻す範囲です。
第3層は、専用のサービスに任せます。
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表を使ってください。
よくある質問
Q1. NetSuiteでメール配信はできますか
簡易な配信はできます。
親ハブの対応表では、CRMのキャンペーン機能で簡易な配信は可能、規模と到達性は専用のサービス、としています。
配信の規模が大きい場合や、開封を細かく分析したい場合は、専用のサービスとつなぐ形が現実的です。
Q2. MAは、ERPの中に入れるべきですか
本格的なMAは専用のサービスに任せるのが基本です。
MAが扱う行動の記録は、第3章の第3層に当たります。
ERPに戻すのは、商談になった見込み客だけで足ります。
CRM・SFA・MAの違いはNetSuiteのCRMとはで解説しています。
Q3. ECは、ERPと一体のものを選ぶべきですか
売り方で変わります。
自社ブランドの直販や取引先向けの受発注なら、ERPと一体のECが候補になります。
国内のモールが売上の中心なら、外部のECとつなぐ形が一般的です（第5章）。
どちらの場合も、注文はERPに集めます。
Q4. コーポレートサイトをERPで作れますか
おすすめしません。
親ハブの対応表でも、NetSuiteのサイトの機能は、コーポレートサイトの用途には不向きとしています。
サイトは第3層です。
専用のサービスで作り、問い合わせの内容だけを戻してください。
Q5. この領域でNetSuiteとOdooのどちらかを選ぶことはありますか
多くの場合ありません。
例外は2つ。1つの仕組みで小さく始めたい場合と、注文から先の流れが重い場合です（第7章）。
それ以外は、会計・販売・在庫の領域で製品を決めた後に、寄せる範囲を設計してください。
まとめ：深さは任せて、お金と顧客は残す
- マーケティング・Web・ECは、ERPにも機能はあるが専用のサービスのほうが深い領域
- 決めるべきは「できるか」ではなく、どこまで寄せるか
- 物差しはお金からの距離。第1層（お金と在庫）は寄せる／第2層（顧客）はつないで戻す／第3層（反応）は任せる
- 戻すのは、層の境目を越えたときだけ
- ECは売り方で分かれる。ただし、注文はどちらの場合もERPに集める
- この領域だけでは製品を決めない
深さで測ると、すべてが外に流れます。
お金からの距離で測れば、深さは専用のサービスに任せながら、注文と顧客はERPに残せます。
まずは、いま使っている仕組みを3つの層に置いてみてください。
もう少し詳しく知りたい方へ
いま使っているECやマーケティングの仕組みを書き出していただければ、寄せる範囲の設計から一緒に始められます。
この領域だけでは製品を決めない、ということもお伝えします。
