6業務のうち5つが「同等」。
Odoo側の対応表で、この領域はそう判定されています。
数だけ見れば、NetSuiteとOdooの差はほとんどないように見えます。
ところが、会社によっては、この領域で製品が決まります。
プロジェクト・現場業務の6業務とは、プロジェクト・工数・問い合わせ管理・現場作業・予約・シフトのことです。
人事やマーケティングと違い、この領域は製品選びの決め手になりえます。
ただし、決め手になるのは自社が「時間」を売っている場合に限られます。
では、時間を売っているかどうかは、どう見分けるのか。
道具は1つです。時間を「予定・実績・請求」の3つの状態に分けます。
会計まわりは会計・請求・経費、販売まわりは販売・CRM・店舗、在庫まわりは在庫・購買・製造で扱いました。
人事まわりは人事・勤怠・給与、マーケティングまわりはマーケ・Web・ECにあります。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、あわせてOdooの導入支援も行っています。
どちらか一方に誘導する立場ではありません。
📌 この記事で分かること
- プロジェクト・工数・問い合わせ・現場作業・予約・シフトの6業務が、①②③のどれになるか
- 時間の3つの状態（予定・実績・請求）とERPが担う範囲
- この領域が製品選びの決め手になる会社、ならない会社
- 問い合わせ管理と現場作業を、どこまでERPに載せるか
- 予約とシフトを、外に置いてよい理由
この領域で見ること｜時間がお金に変わる流れ
判定は3つ
判定の言葉は、親ハブの記事と同じ定義です。
①標準で足りるとは、NetSuiteの標準機能に同じ業務範囲があり、追加の開発が要らない状態のことです。
②拡張で補うとは、標準にはないものの、項目・レコード・ワークフローを組み合わせて作れる状態を指します。
③連携するは、相手側の商流や法制度への対応が価値の源泉であり、専用のサービスを残してつなぐ状態です。
45アプリ全体の対応表はOdooのアプリはNetSuiteで何に当たるかにあります。
ここまでの5本と、問いが変わる
| 記事 | 読者の問い |
|---|---|
| 会計・請求・経費 | 残すか、寄せるか（③になる理由） |
| 販売・CRM・店舗 | 作るか、あきらめるか（②になる条件） |
| 在庫・購買・製造 | どこまでの深さが要るか |
| 人事・勤怠・給与 | そもそも比べる必要があるか |
| マーケ・Web・EC | ERPに、どこまで寄せるか |
| 本記事 | 自社は時間を売っているか |
人事とマーケティングの記事では、「この領域だけで製品は決まらない」と書きました。
この領域は違います。
会社によっては、ここで製品が決まります。
その境目が、時間を売っているかどうかです。
6業務の判定表
親ハブの対応表と、Odoo側の対応表を並べます。
| 業務（Odooのアプリ） | NetSuiteでの実現 | NetSuite側の判定 | Odoo側の関係 |
|---|---|---|---|
| プロジェクト（Project） | プロジェクト管理の標準機能。工数・請求・採算まで扱う機能は追加ライセンス | ① | 同等 |
| 工数（Timesheets） | 工数入力の標準機能。請求・原価につながる | ① | 同等 |
| 問い合わせ管理（Helpdesk） | 問い合わせ（ケース）管理が標準。SLAや複数の窓口の本格運用は連携 | ①／③ | 同等 |
| 現場作業（Field Service） | フィールドサービスの機能の🌏日本での提供状況は要確認 | ①／③ | — |
| 予約（Appointments） | 標準にはない。簡易な予約受付は拡張で作れる | ②／③ | 同等 |
| シフト（Planning） | 店舗シフトの機能は標準にない | ③ | 同等 |
SLA（サービスレベル合意）とは、問い合わせに何時間以内に応えるかなど、対応の水準を取り決めたものです。
表には、両者の性格の違いがはっきり出ています。
- Odoo側：6業務のうち5つが「同等」。どれも単機能のアプリとして持っている
- NetSuite側：プロジェクトと工数は①。予約とシフトは②や③
親ハブの記事は、NetSuiteの標準が厚い領域の1つにプロジェクトを、Odooが軽い単機能を持つ領域の1つに予約を挙げています。
この領域の中に、両方の性格が同居しているわけです。
🌏 フィールドサービスの提供状況は、契約内容と時期によって変わります。導入時に最新の公式情報でご確認ください。機能の概要はNetSuiteのフィールドサービス管理で扱っています。
時間の3つの状態｜予定・実績・請求
この領域の6業務は、すべて人の時間を扱います。
そして時間には、3つの状態があります。
| 状態 | 何を表すか | 主な業務 | 置き場所の基本 |
|---|---|---|---|
| 予定の時間 | 誰が、いつ、何をする予定か | 予約、シフト、作業の割り当て | 外でもよい |
| 実績の時間 | 誰が、何に、何時間かけたか | 工数、作業の報告、問い合わせへの対応 | ERP |
| 請求の時間 | その時間が、いくらの売上・原価になったか | 請求、採算、原価 | ERPの中核 |
予定の時間は、外でもよい
予約やシフトは、変更が多く、現場で頻繁に触るものです。
画面の使いやすさや、スマートフォンでの操作が効いてきます。
そして予定の段階では、まだお金は動いていません。
予定が変わっても、会計の数字は変わらないのです。
だから、予定の時間を専用のサービスに置いても、困ることは少なくなります。
親ハブの判定で予約とシフトが②や③になっているのは、この性質のためです。
実績の時間は、ERPに置く
実際にかかった時間は、原価の材料です。
誰が、どの案件に、何時間かけたか。
これが分かって初めて、案件ごとの原価が計算できます。
工数の取り方そのものは、工数管理を「現場の作業」で終わらせないで扱っています。
請求の時間は、ERPの中核
時間を売る会社では、実績の時間がそのまま請求の金額になります。
作業した時間に単価を掛けて請求する。
あるいは、進み具合に応じて売上を計上する。
どちらでも、時間と会計が直結します。
NetSuiteのプロジェクト管理で採算まで見られることは、NetSuiteのプロジェクト管理機能とはで解説しています。
3つの状態で、製品の差が出る場所が分かる
| 状態 | Odoo | NetSuite |
|---|---|---|
| 予定の時間 | 予約・シフトを単機能のアプリとして持つ | 標準にないものが多い。作るか、つなぐ |
| 実績の時間 | 工数のアプリを持つ | 工数は標準。原価につながる |
| 請求の時間 | 同じデータベースの上で請求につながる | 採算・請求まで扱う機能は追加ライセンス。会計と一体 |
予定の時間はOdooが軽く請求の時間はNetSuiteが厚い。
どちらが自社にとって重いかで、この領域の答えが変わります。
この領域が、製品の決め手になる会社
見分ける問いは1つ
自社の売上の大きな部分が人の時間から生まれているか。
冒頭の問いへの答えは、この1問です。
答えごとの分かれ方を図にすると、次のとおりです。
たとえば、次のような会社が「はい」になります。
- 受託開発、システムの導入、コンサルティング
- 広告の制作、設計、調査など、案件ごとに人が動く仕事
- 機器の据え付けや保守など、技術者が現場に出向く仕事
こうした会社では、時間が在庫であり、原価でもあります。
公開中のSuiteProjects Proの記事も、こうした会社を対象にした仕組みとして解説しています。
時間を売る会社では、請求の時間の深さが効く
時間を売る会社で重いのは、請求の時間です。
案件が同時に多く動く。
複数の会社や通貨をまたぐ。
進み具合に応じて売上を計上する必要がある。
こうした要件があるなら、請求の時間を会計と一体で扱える深さが、製品の決め手になります。
NetSuiteの標準の機能と、より大規模な案件管理の仕組みの違いは、SuiteProjects Proの記事にまとめています。
時間を売る会社でも、Odooが合う場合
一方で、次のような場合は、Odooの軽さが生きます。
- 案件の数が少なく、単価と時間の掛け算で請求が済む
- 予約やシフトなど、予定の時間の管理が業務の中心
- 1つの会社・1つの通貨で完結している
予定の時間が中心で、請求の時間が単純な会社です。
予約・シフト・工数・請求を1つの仕組みで軽く回せることが、そのまま利点になります。
時間を売っていない会社では、決め手にならない
モノを売る会社では、この領域は脇役です。
工数は、製造原価の一部として取ります。
問い合わせ管理や予約は、販売を支える仕組みです。
製品は、在庫・購買・製造や会計・請求・経費の領域で決まります。
問い合わせ管理と現場作業は、どこまで載せるか
6業務のうち、問い合わせ管理と現場作業は①／③です。
ERPの中で始められるものの、本格的に運用すると専用のサービスが要ります。
問い合わせ管理
| 使い方 | 置き場所 | 理由 |
|---|---|---|
| 顧客ごとの問い合わせの記録 | ERP（標準） | 取引や請求と同じ顧客に紐づけられる |
| 対応の期限（SLA）の管理 | 専用のサービス | 本格的な運用は連携が前提（親ハブの判定） |
| 電話・メール・チャットなど複数の窓口 | 専用のサービス | 同上 |
分かれ目は、問い合わせを「売上につながる記録」として見るか、「対応の品質」として見るかです。
記録として顧客に紐づけたいなら、ERPで足ります。
対応の品質を細かく管理したいなら、専用のサービスとつなぎます。
現場作業
技術者が顧客のもとへ出向く仕事では、現場作業の管理が、実績の時間と部品の在庫の両方に関わります。
- 誰がいつ行くか → 予定の時間
- 何時間かかったか、何の部品を使ったか → 実績の時間と在庫
- 保守の契約に含まれるか、別に請求するか → 請求の時間
3つの状態をすべて通る業務です。
だから、会計や在庫と切り離すと、請求漏れや部品の数のずれが起きやすくなります。
予約とシフトは、外に置いてよい
予約とシフトは、予定の時間です。
親ハブでも、予約は②／③、シフトは③と判定しています。
外に置くときに決める2つのこと
| # | 決めること | 決まっていないと |
|---|---|---|
| 1 | 予定が実績になったとき何をERPに渡すか | 予約した作業の時間が、工数として記録されない |
| 2 | 顧客をどちらで作るか | 予約した人と、請求先の顧客が別人になる |
渡すのは、予定が実績に変わった後だけで足ります。
予約の変更やキャンセルのたびに、ERPへ渡す必要はありません。
外に置いたときの流れは、次のとおりです。
簡易な予約受付は、作ることもできる
親ハブでは、簡易な予約受付は拡張で作れるとしています。
取引先からの作業依頼を受け付け、そのまま案件や作業に紐づけたいなら、作る選択肢があります。
作るかどうかは、販売・CRM・店舗の記事の「②になる条件」に当てはめて決めます。
AIとの親和性
時間の3つの状態は、AIの使いやすさとも関わります。
| 状態 | AIとの親和性 | 理由 |
|---|---|---|
| 予定の時間 | 専用のサービス側で高い | 日程の調整や割り当ての候補出しは、専用のサービスの機能に任せやすい |
| 実績の時間 | 高い | 工数と案件がERPで紐づいていれば、作業の傾向の要約をAIに任せやすい |
| 請求の時間 | 高い | 案件ごとの採算が1か所で見えれば、採算が悪化しそうな案件の洗い出しに使える |
どの状態でも、判断そのものは人が行います。
AIに任せるのは、材料の整理と下書きです。
つまずく3つのパターン
パターン1：予定の時間の使いやすさだけで、製品を決める
現象
予約やシフトの画面の使いやすさを比べて、製品を決める。
運用を始めてから、案件ごとの採算が見えないことに気づく。
構造的な原因
予定の時間と請求の時間を同じ重さで見ているためです。
時間を売る会社で重いのは、請求の時間のほうです。
回避策
第4章の問い「売上の大きな部分が、人の時間から生まれているか」に先に答えてください。
「はい」なら、請求の時間の深さから比べます。
パターン2：勤怠の時間と、案件の工数を1つにまとめる
現象
出退勤の時間から、案件の工数を作ろうとする。
案件ごとの内訳が取れず、採算が見えないまま運用が始まる。
構造的な原因
目的の違う2つの時間を同じものとして扱っているためです。
勤怠は労務管理のため、工数は原価と採算のためのものです。
回避策
勤怠と工数は、別に設計してください。
この区別は、人事・勤怠・給与の記事の第5章でも扱っています。
パターン3：現場作業を、会計や在庫から切り離して入れる
現象
現場作業の管理だけを、専用の仕組みで始める。
使った部品が在庫に反映されず、保守の契約外の作業も請求から漏れる。
構造的な原因
現場作業が3つの状態をすべて通る業務だと捉えていないためです。
公開中のフィールドサービス管理の記事でも、切り離した導入を避けるよう書いています。
回避策
現場作業は、実績の時間・部品の在庫・請求の3つにつながる前提で設計します。
専用の仕組みを使う場合も、この3つをERPに戻す流れを先に決めてください。
ベンチャーネットならこう見る｜時間の流れを見える化してから選ぶ
型1：予定→実績→請求の流れを、先に描く
ベンチャーネットは、製品の比較より先に業務の見える化から入ります。
この領域で描くのは、時間の流れです。
- 見える化：予約・割り当てから、工数の報告、請求までを、いまの仕組みと担当者の名前で書き出す
- 整理整頓：二重に入力している時間、請求に届かず消えている実績を洗い出す
- Fit&Gap：残った流れを、NetSuiteかOdooの標準機能と照らし合わせる
描いてみると、請求の時間がどれだけ重いかが見えます。
重ければ、第4章の「はい」の会社です。
型2：予定は「残す」、実績と請求は「標準に合わせる」
図の3つの選択は、時間の3つの状態にそのまま当てはまります。
予定の時間は、専用のサービスを残してつなぐ。
実績と請求の時間は、ERPの標準に合わせる。
簡易な予約受付のように、あいだをつなぐ仕組みだけを開発します。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
この領域で引き受けるのは、時間を売っているかの見極め、時間の流れの設計、連携と足りない仕組みの開発の3つです。
時間を売る会社でも、請求の時間が単純なら、Odooのほうが合うとお伝えすることもあります。
今日できること｜1つの問いと、6業務の置き場所
最初に、1つの問いに答えてください。
自社の売上の大きな部分が人の時間から生まれているか。
「はい」なら、この領域は製品選びの決め手になります。
請求の時間（採算・請求・売上の計上）に求める深さを、先に書き出してください。
次に、6業務を3つの状態に置いてみます。
- 予定の時間：予約・シフト・作業の割り当て → 外でもよい
- 実績の時間：工数・作業の報告・問い合わせへの対応 → ERP
- 請求の時間：請求・採算・原価 → ERPの中核
45アプリ全体で同じ棚卸しをするなら、OdooのアプリはNetSuiteで何に当たるかの対応表を使ってください。
よくある質問
Q1. NetSuiteの標準で、プロジェクトの採算は見られますか
プロジェクト管理と工数は標準です。
親ハブの対応表では、工数・請求・採算まで扱う機能は追加ライセンスとしています。
採算の見え方は、NetSuiteのプロジェクト管理機能とはで解説しています。
Q2. SuiteProjects Proは、どんな会社に必要ですか
案件が多く人の割り当てや採算の管理が複雑な会社です。
標準の機能で足りる会社も多くあります。
違いはSuiteProjects Proの記事にまとめています。
Q3. 問い合わせ管理は、ERPの中で足りますか
顧客ごとの記録として使うなら標準で足ります。
対応の期限の管理や、電話・メール・チャットなど複数の窓口をまとめる本格的な運用は、専用のサービスとつなぐ形が前提です（第5章）。
Q4. 予約やシフトは、ERPで管理しないと困りますか
多くの場合困りません。
予約やシフトは予定の時間で、まだお金は動いていません。
専用のサービスに置き、予定が実績になった後に、工数としてERPへ渡せば足ります（第6章）。
Q5. この領域で、NetSuiteとOdooのどちらかを選ぶことはありますか
時間を売っている会社ではあります。
請求の時間（採算・請求・売上の計上）の深さが要るならNetSuite、予定の時間が中心で請求が単純ならOdooが合いやすくなります。
時間を売っていない会社では、この領域は決め手になりません（第4章）。
まとめ：時間を売っているなら、請求の時間で選ぶ
- この領域の6業務は、すべて人の時間を扱う
- 時間には3つの状態がある。予定は外でもよい／実績はERP／請求はERPの中核
- 予定の時間はOdooが軽く請求の時間はNetSuiteが厚い
- 自社が時間を売っているなら、この領域は製品選びの決め手になる
- 問い合わせ管理と現場作業は、ERPで始められるが、本格運用では専用のサービスとつなぐ
- 予約とシフトは外に置き、予定が実績になった後だけERPに渡す
時間を売る会社にとって、時間は在庫であり、原価でもあります。
予定の使いやすさではなく、請求の時間をどこまで深く扱えるかで選んでください。
まずは、売上の大きな部分が人の時間から生まれているかに、自社の数字で答えるところからです。
もう少し詳しく知りたい方へ
案件の数、請求の方法、現場に出る人の数を教えていただければ、この領域が製品の決め手になるかどうかから一緒に見ていけます。
