監査の場で、「この発注は誰が認めたのですか」と聞かれる。
担当者がチャットを遡ると、上司の「了解です」が1行だけ残っていた。
ERPの発注には、承認の記録がありません。
承認・チャット・電話・IoTの4業務は、どれも業務と業務の間を流れる「やりとり」です。
NetSuiteにもOdooにも、それぞれの機能があります。
ただし、ERPに残すべきものは一部だけです。
では、何を残し、何を外に流してよいのか。
決め手は、1つの問いで足ります。
後からそのことを説明するよう求められるか。
会計まわりは会計・請求・経費、販売まわりは販売・CRM・店舗、在庫まわりは在庫・購買・製造で扱いました。
人事は人事・勤怠・給与、マーケティングはマーケ・Web・EC、プロジェクトはプロジェクト・現場業務にあります。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、あわせてOdooの導入支援も行っています。
どちらか一方に誘導する立場ではありません。
📌 この記事で分かること
- 承認・社内チャット・電話・IoTの4業務が、①②③のどれになるか
- ERPに残すかどうかを決める問い「後から説明を求められるか」
- 情報を「決定・会話・信号」の3種類に分ける方法
- チャットや電話から、何をERPに戻せばよいか
- IoTの大量のデータを、どこまでERPに入れるか
この領域で見ること｜残すか、流すか
判定は3つ
判定の言葉は、親ハブの記事と同じ定義です。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態を指します。
③連携するは、相手側の商流や法制度への対応が価値の源泉であり、専用のサービスを残してつなぐ状態です。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
ここまでの6本と、問いが変わる
| 記事 | 読者の問い |
|---|---|
| 会計・請求・経費 | 残すか、寄せるか（③になる理由） |
| 販売・CRM・店舗 | 作るか、あきらめるか（②になる条件） |
| 在庫・購買・製造 | どこまでの深さが要るか |
| 人事・勤怠・給与 | そもそも比べる必要があるか |
| マーケ・Web・EC | ERPに、どこまで寄せるか |
| プロジェクト・現場業務 | 自社は、時間を売っているか |
| 本記事 | 後から説明を求められるか |
ここまでの記事は、どれも「業務」を単位に考えてきました。
この領域の4業務は、性質が少し違います。
業務そのものではなく、業務と業務の間を流れるやりとりを扱います。
やりとりは量が多く、すべてをERPに入れると、かえって必要なものが埋もれます。
だから、残すものを選ぶ基準が要ります。
4業務の判定表
親ハブの対応表と、Odoo側の対応表を並べます。
| 業務（Odooのアプリ） | NetSuiteでの実現 | NetSuite側の判定 | Odoo側の関係 |
|---|---|---|---|
| 承認（Approvals） | 発注・経費・請求など業務の承認は標準のワークフロー。紙の稟議に当たる汎用の申請は、レコードとワークフローで作る | ①／② | 同等 |
| 社内チャット（Discuss） | チャット機能は標準にない。レコード上のメモと、外部のチャットへの通知で代替 | ③ | 一部重なる |
| 電話（VoIP） | 電話連携の機能あり（🌏要確認） | ①／③ | — |
| IoT（IoT） | 標準にはない。APIで現場の数値を取り込む | ③ | — |
稟議（りんぎ）とは、担当者が作った申請を、関係者が順に確認して承認する、日本の会社でよく使われる決裁の進め方です。
IoTは、機械やセンサーをネットにつなぎ、温度や稼働の状況などのデータを自動で集める仕組みを指します。
承認は「アプリがない」のではない
親ハブの記事は、ここが誤解されやすい点だとしています。
NetSuiteに承認アプリがないのではありません。
業務の承認は標準にあり、汎用の申請を作る余地が残っている、という関係です。
Odoo側の記事でも、各アプリに組み込まれた承認と、汎用の承認アプリは別物とされています。
NetSuiteも同じ構造です。
承認の設定方法と、稟議をNetSuiteで扱う型は、NetSuiteの承認ワークフローで解説しています。
チャットは、どちらの製品でも専用ツールが強い
Odoo側の対応表は、チャットを「一部重なる」としています。
Odooのチャットは、業務の記録に紐づく会話に強い。
一方で、社外とのやりとりや外部との連携の広さでは、専用ツールが先行している、という見方です。
NetSuite側は③で、外部のチャットに通知する形で補います。
🌏 電話連携の機能の提供状況は、契約内容と時期によって変わります。導入時に最新の公式情報でご確認ください。
残すかどうかの問い｜後から説明を求められるか
この領域のやりとりは、3種類に分けられます。
| 種類 | どんなやりとりか（例） | 後から説明を求められるか | 置き場所 |
|---|---|---|---|
| 決定 | 誰が、いつ、何を認めたか（発注の承認、稟議の決裁） | 求められる | ERPに残す |
| 会話 | 決定に至るまでの相談や連絡（チャット、電話） | ほとんど求められない | 外に流し結論だけ戻す |
| 信号 | 機械が自動で出す数値（温度、稼働時間、計数） | 個々には求められない | 外で集め意味のある事象だけ戻す |
決定は、ERPに残す
承認は、後から必ず説明を求められます。
この発注は誰が認めたのか。
その人に、認める権限はあったのか。
監査や内部統制の確認では、こうした問いに答えなければなりません。
だから、決定は取引と同じ場所に残します。
取引の記録と承認の記録が別の仕組みにあると、突き合わせに手間がかかります。
公開中の承認ワークフローの記事でも、承認の設計は、職務の分担と権限の設計とあわせて行うよう書いています。
会話は、外に流して結論だけ戻す
チャットや電話のやりとりは、量が多く、話題もさまざまです。
後から「あのとき何を話したか」を正式に説明する場面は、多くありません。
残す価値があるのは、会話そのものより、会話で決まったことです。
取引先との電話で、納期が変わった。
チャットで、値引きの相談がまとまった。
こうした結論だけを該当する取引の記録に書き残せば足ります。
信号は、外で集めて意味のある事象だけ戻す
IoTのデータは、1台の機械からでも絶えず届きます。
1つ1つの数値を、後から説明する必要はありません。
要るのは、数値が意味を持った瞬間です。
- 温度が決められた範囲を外れた
- 稼働時間が点検の目安に達した
- 製造の個数が予定に届いた
こうした事象だけをERPに戻せば、在庫や保全、原価の判断に使えます。
なぜ「後から説明を求められるか」なのか
ERPの強みは、記録が消えず、誰がいつ何をしたかをたどれることです。
その強みが生きるのは、後から説明を求められる情報です。
会話や信号をすべてERPに入れても、その強みは生きません。
むしろ、必要な記録が大量のやりとりに埋もれます。
残す基準を「便利かどうか」ではなく、「説明を求められるかどうか」に置く。
それで、ERPを記録の場所として保てます。
冒頭の問いへの答えは、この基準です。
4業務を3種類に置くと
| 業務 | 主な種類 | ERPに残すもの | 外に任せるもの |
|---|---|---|---|
| 承認 | 決定 | 承認した人・日時・対象の取引 | 承認前の相談 |
| 社内チャット | 会話 | 会話で決まった結論（取引の記録に書く） | 会話そのもの |
| 電話 | 会話 | 取引に関わる結論、必要なら通話の記録 | 通話そのもの |
| IoT | 信号 | 意味のある事象（範囲外・点検時期・個数の到達） | 絶え間なく届く数値 |
汎用の稟議は、作るかどうかを決める
承認のうち、発注・経費・請求など業務に組み込まれた承認は標準です。
紙の稟議に当たる汎用の申請は、レコードとワークフローで作る領域です。
作るかどうかは、販売・CRM・店舗の記事の「②になる条件」に当てはめて決めます。
作り方はNetSuiteの承認ワークフローにまとめています。
親ハブの対応表では、承認の連携先として、専用の稟議サービスも挙げています。
その場合も、決定の結果は取引と同じ場所に戻すのが基本です。
通知は、外のチャットへ送る
チャットには、ERPから外へ向かう流れもあります。
承認の依頼や在庫の不足などを、ふだん見ているチャットに知らせる使い方です。
公開中のNetSuiteとSlack・Chatworkの連携では、通知と承認を「いつも見ている場所」に寄せる方式を解説しています。
通知は外へ送り決定はERPに戻す。
この往復が、この領域の基本の形です。
往復を図にすると、次のとおりです。
電話は、取引に紐づけたいときだけつなぐ
電話は、親ハブで①／③とされています。
連携の機能はありますが、提供状況は導入時に確かめる必要があります。
つなぐかどうかは、通話を取引や顧客の記録に紐づけたいかで決めます。
- 取引先からの電話で、注文や納期が決まることが多い → つなぐ価値がある
- 電話は主に社内の連絡や、取引に関わらない問い合わせ → 外のままでよい
つなぐ場合も、残すのは通話そのものではありません。
誰といつ話し何が決まったかを、顧客や取引の記録に残せば足ります。
通話の録音や文字起こしは、電話の仕組みの側で保管します。
AIとの親和性
3種類のやりとりは、AIの使いやすさとも関わります。
| 種類 | AIとの親和性 | 理由 |
|---|---|---|
| 決定 | 高い | 承認の記録が取引と同じ場所にあれば、承認の滞りや偏りの洗い出しに使いやすい |
| 会話 | 中くらい | 会話の要約はAIの得意分野。ただし結論を取引に書き戻すのは人の役目 |
| 信号 | 高い（外の仕組みで） | 大量の数値から異常の兆しを探すのは、専用の仕組みとAIの組み合わせが向く |
どの種類でも、AIが出すのは材料と下書きです。
承認すること、結論を記録に残すことは、人が行います。
この領域は、製品選びの決め手になるか
正直に書きます。
承認・チャット・電話・IoTの領域だけで、NetSuiteとOdooのどちらかを選ぶ理由は、多くの場合立ちません。
理由は3つです。
- 承認は、どちらの製品でも業務に組み込まれた形で持っている
- チャットは、社外とのやりとりまで含めると、どちらの製品でも専用ツールが強い
- IoTは、どちらの製品でも、外で集めて必要なものだけ戻す形になる
例外は1つです。
社内のやりとりを、業務の記録に紐づけて1つの仕組みで完結させたい場合。
Odooは社内チャットを業務の記録に紐づく形で持っています。
社外とのやりとりが少ない会社なら、この点でOdooのほうが手軽に感じられるはずです。
それ以外は、会計・販売・在庫の領域で製品を決めてから、3種類に沿って設計してください。
つまずく3つのパターン
3つのパターンを、先に図で示します。
パターン1：承認を、チャットの「了解です」で済ませる
現象
急ぎの発注を、チャットで上司に確認して進める。
ERPには承認の記録が残らず、監査で「誰が認めたのか」を説明できない。
構造的な原因
決定と会話を同じものとして扱っているためです。
チャットの「了解です」は会話です。
取引と結びついた決定の記録ではありません。
回避策
チャットは、承認を依頼する通知の場所として使ってください。
承認そのものはERPで取引に対して行います。
パターン2：会話をすべてERPに残そうとする
現象
「記録はすべてERPに」と考え、チャットや電話の内容をまとめて取り込む。
取引の記録が長い会話で埋まり、肝心の結論が見つからない。
構造的な原因
残すことと説明できることを混同しているためです。
量が多いほど、必要な記録は探しにくくなります。
回避策
会話からは、取引に関わる結論だけを書き戻します。
会話そのものは、チャットや電話の仕組みで検索できれば足ります。
パターン3：IoTの数値を、すべてERPに流し込む
現象
機械の数値を、届いたまますべてERPに送る。
データの量が増えて処理が重くなり、本当に見るべき異常が埋もれる。
構造的な原因
信号と事象を分けていないためです。
ERPが使うのは、数値が意味を持った瞬間だけです。
回避策
数値は外の仕組みで集め、決めた条件を超えたときだけERPに戻してください。
条件は、在庫・保全・原価のどの判断に使うかから逆算して決めます。
ベンチャーネットならこう見る｜決定は「標準に合わせる」、会話と信号は「残す」
型1：やりとりを見える化してから仕分ける
ベンチャーネットは、比較の前に業務の見える化から入ります。
この領域で書き出すのは、社内で行き交うやりとりです。
承認の依頼がどこで出て、どこで認められ、どこに記録が残っているか。
書き出すと、チャットで済ませている承認が見つかることがあります（パターン1）。
それが、最初に手をつける場所です。
型2：3種類を、3つの選択に当てはめる
仕分けたあとは、ベンチャーネットが導入で使う3つの選択に当てはめます。
| 種類 | 選択 | この領域でやること |
|---|---|---|
| 決定（業務の承認） | 標準に合わせる | 発注・経費・請求の承認を、標準のワークフローに乗せる |
| 決定（汎用の稟議） | 開発する | 標準にない申請を、レコードとワークフローで作る |
| 会話・信号 | 残す | チャット・電話・IoTの仕組みを残し、結論と事象だけ戻す |
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
この領域で引き受けるのは、残すものを決めること、承認の設計と足りない申請の開発、連携の実装の3つです。
外部のチャットへの通知や、電話・IoTの仕組みからERPへ結論や事象を戻す流れを作ります。
そして、この領域だけで製品を決めないよう、はっきりお伝えします。
今日できること｜1つの問いで仕分ける
社内で行き交っているやりとりを、いくつか書き出してください。
そして1つずつ、次の問いに通します。
後からそのことを説明するよう求められるか。
- 求められる（決定） → ERPの取引の上に残す
- ほとんど求められない（会話） → 外に流し、結論だけを取引に書き戻す
- 個々には求められない（信号） → 外で集め、意味のある事象だけを戻す
いまチャットで済ませている承認がないかも、あわせて見てください。
見つかれば、そこが最初に手をつける場所です。
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表を使ってください。
よくある質問
Q1. NetSuiteに承認の機能はありますか
あります。
発注・経費・請求など、業務に組み込まれた承認は標準のワークフローで扱えます。
紙の稟議に当たる汎用の申請は、レコードとワークフローで作る領域です。
詳しくはNetSuiteの承認ワークフローをご覧ください。
Q2. 承認をチャットの中で行ってもよいですか
承認の依頼や通知はチャットで受け取って構いません。
ただし、承認そのものはERPで取引に対して行い、記録を残してください。
チャットの「了解です」は、後から誰が認めたかを説明する記録になりにくいためです（第7章）。
Q3. チャットの履歴は、ERPに残すべきですか
多くの場合必要ありません。
残すのは、取引に関わる結論だけで足ります。
会話そのものは、チャットの仕組みの中で検索できれば十分です（第3章）。
Q4. IoTのデータは、NetSuiteに直接入れられますか
APIで取り込むことはできます。
親ハブの対応表では、IoTは標準にはなく、APIで現場の数値を取り込む形としています。
ただし、すべての数値を入れるのではなく、決めた条件を超えた事象だけを戻す設計をおすすめします。
Q5. この領域で、NetSuiteとOdooのどちらかを選ぶことはありますか
多くの場合ありません。
例外は、社内のやりとりを業務の記録に紐づけて、1つの仕組みで完結させたい場合です（第6章）。
それ以外は、会計・販売・在庫の領域で製品を決めてから設計してください。
まとめ：残すのは、後から説明を求められるものだけ
- 承認・チャット・電話・IoTは、業務の間を流れるやりとりを扱う
- 残すかどうかの問いは1つ。後から説明を求められるか
- 決定はERPに残す／会話は外に流して結論だけ戻す／信号は外で集めて事象だけ戻す
- 通知は外へ送り決定はERPに戻す。この往復が基本の形
- 承認は、どちらの製品にもある。汎用の稟議は作るか、専用のサービスとつなぐ
- この領域だけでは製品を決めない
ERPの強みは、誰がいつ何をしたかをたどれることです。
冒頭の「了解です」の1行を、取引の上の承認に置き換える。
残すものを選ぶ作業は、そこから始められます。
もう少し詳しく知りたい方へ
いまの承認の流れと、使っているチャットや電話の仕組みを教えていただければ、ERPに残すものの設計から一緒に始められます。
この領域だけでは製品を決めない、ということもお伝えします。
