「受注はCRMに記録しているのに、発注管理はExcelの別ファイルで行っている」「営業が受注した案件の納品状況がわからず、顧客に聞かれても即答できない」——BtoBの受発注プロセスとCRMが分断されていることで、こうした問題に悩む企業は少なくありません。
CRM × 受発注管理の連携とは、CRMの顧客・取引データと受発注プロセス(見積→受注→発注→納品→検収)を統合的に設計し、営業からバックオフィスまで一気通貫でデータが流れる仕組みを構築するアプローチです。
この記事では、BtoB取引の受発注プロセスをCRMと連携させる設計パターンから、具体的な実装方法、そしてよくある失敗パターンまでを解説します。
CRM × 受発注管理の連携とは、営業が管理する顧客・商談データと、バックオフィスが管理する受発注・納品・検収データを、一つのデータフローとして設計・統合することです。
従来のBtoB企業では、営業プロセス(リード獲得→商談→受注)と業務プロセス(受注→発注→納品→検収→請求)が別々のシステムで管理されていることが一般的です。営業はCRMやSFA、バックオフィスはERP(基幹システム)やExcel/スプレッドシートでそれぞれ独立して管理しているケースが多いかなと思います。
この分断を解消し、受注した案件がシームレスに発注・納品・検収のフローへとつながり、その進捗を営業もリアルタイムに把握できる状態を作ることが、CRM × 受発注連携の目的です。
多くのBtoB企業では、受注後の業務プロセスに手作業が多く残っています。
| 業務 | 手作業のケース | 問題点 |
|---|---|---|
| 受注伝達 | 営業がメールやチャットで事務に連絡 | 伝達漏れ、情報の欠落 |
| 発注書作成 | Excelテンプレートに手入力 | 転記ミス、最新テンプレ不明 |
| 納期管理 | スプレッドシートで個別管理 | ステータス更新漏れ |
| 検収確認 | メールで個別確認 | 確認漏れ、対応遅延 |
| 在庫確認 | 電話やメールで都度確認 | 即時回答不可、二重受注リスク |
スプレッドシートで結構管理されている企業様が多いかなと思いますが、こうした手作業はデータ量が増えるほど限界が見えてきます。特に月間の取引件数が50件を超えるあたりから、手動管理のリスクとコストが急増します。
営業が顧客から「あの案件、いつ納品されますか?」と聞かれた際、受発注の情報がCRMから見えなければ、営業はバックオフィスに確認を取る必要があります。この「確認のための確認」が日常的に発生すると、営業の生産性が下がるだけでなく、顧客体験も低下します。
CRMに受発注の進捗が連携されていれば、営業は顧客の問い合わせに即座に回答でき、プロアクティブな対応も可能になります。
受注データと発注データが分断されていると、「売上は立つが、原価(外注費・仕入れ)がいくらかかるのか」を横断的に把握できません。CRMの受注データと発注データが統合されていれば、案件別の粗利をリアルタイムに確認でき、より正確な経営判断が可能になります。
BtoBの受発注プロセスとCRMの連携は、以下のフローで設計します。
[営業プロセス(CRM)] [業務プロセス(受発注管理)]
リード獲得
↓
商談管理
↓
見積作成 ←→ 見積承認
↓
受注 ─────────────→ 発注処理
↓
納品管理
↓
請求処理 ←──────── 検収完了
↓
入金管理
ここでポイントになってくるのが、「受注」から「発注処理」への自動連携と、「検収完了」から「請求処理」へのフィードバックです。この2つの接続ポイントを自動化することで、全体フローが一気通貫で流れるようになります。
CRMと受発注管理を連携するためのデータモデルは、以下のオブジェクトで構成します。
| オブジェクト | 役割 | 主要プロパティ |
|---|---|---|
| 会社 | 取引先(顧客・仕入先) | 会社名、業種、取引区分 |
| コンタクト | 顧客の担当者 | 氏名、役職、部署 |
| 取引(受注) | 営業の受注案件 | 受注金額、受注日、支払条件 |
| 発注(カスタムオブジェクト) | 仕入先への発注案件 | 発注金額、発注先、納期 |
| 納品(カスタムオブジェクト) | 納品の管理 | 納品日、数量、検収状況 |
取引(受注)と発注を関連付けることで、1つの受注案件に対して複数の発注が紐づく1対多の構造を表現できます。例えば、顧客に対してシステム開発を受注した場合、開発の外注先A社への発注とインフラの仕入先B社への発注を、それぞれ独立した発注レコードとして管理できます。
受発注の進捗管理には、パイプライン型のステータス管理が有効です。
受注パイプライン:
見積作成 → 見積提出 → 受注内示 → 契約締結 → 納品中 → 検収完了 → 請求済み
発注パイプライン:
発注準備 → 発注済み → 納品待ち → 検品中 → 受入完了 → 支払処理中 → 支払完了
各ステージに必須プロパティを設定し、ステージ移行時にデータの入力を強制することで、データ品質を担保します。これはCRMのパイプライン設計と同じ考え方です。
HubSpotのEnterpriseプランでは、カスタムオブジェクトを作成して発注管理を実装できます。
「発注」カスタムオブジェクトの設計例:
| プロパティ名 | タイプ | 説明 |
|---|---|---|
| 発注番号 | テキスト(ユニーク) | 発注を一意に識別するID |
| 発注先 | 会社オブジェクトとの関連 | 仕入先の会社レコード |
| 発注金額 | 通貨 | 発注金額 |
| 発注日 | 日付 | 発注の実行日 |
| 納期 | 日付 | 納品予定日 |
| ステータス | ドロップダウン | 発注済み/納品待ち/検品中/完了 |
| 関連取引 | 取引との関連 | 受注案件との紐づけ |
このカスタムオブジェクトを取引(受注)と関連付けることで、受注案件と発注案件が紐づいた状態で管理できます。
受発注のフローを効率化するワークフローの設計例です。
経営判断に必要な指標をダッシュボードで可視化します。
営業会議用と経営会議用でダッシュボードを分けて構築すると、各シーンで必要な情報に集中できます。
HubSpotだけで受発注管理を完結できないケースでは、既存の受発注管理システムやERPとの連携が必要です。
| 連携パターン | 具体例 | 推奨連携方法 |
|---|---|---|
| CRM → ERP | 受注データをERPの受注伝票に連携 | iPaaS(Zapier/Make) |
| ERP → CRM | 納品ステータスをCRMに同期 | iPaaS or API |
| CRM → 在庫管理 | 受注時に在庫引当を自動チェック | API連携 |
| CRM → 会計ソフト | 検収完了→請求書自動発行 | iPaaS(Yoom推奨) |
日系のSaaSツール(kintone、クラウドサインなど)との連携が多い場合は、Yoomが使いやすいかなと思います。
「同じ案件の情報がCRMにも受発注システムにもある」状態で、どちらが正(マスター)かが定義されていないと、データの不整合が発生します。原則として、顧客・商談情報のマスターはCRM、発注・在庫情報のマスターはERPまたは受発注管理システムとし、連携の方向を明確にしましょう。
BtoB企業の発注パターンは多岐にわたります(定型発注、スポット発注、外注、仕入れなど)。すべてを一度にシステム化しようとすると、設計が複雑になり、導入が遅延します。まずは売上・発注金額のボリュームが大きい主要パターンから着手し、スモールスタートで進めるのが推奨です。
システム上は美しい連携フローを設計しても、現場の担当者が使いこなせなければ意味がありません。特に「入力項目が多すぎる」「承認フローが煩雑」といった問題は、現場の負担増とデータ品質低下を招きます。項目は最小限に絞り、必須項目も本当に必要なものだけに限定する設計哲学が大事です。
HubSpotは営業・マーケティングのCRMとしては非常に強力ですが、本格的な受発注管理(在庫管理、ロット管理、製造指示など)の機能は備えていません。製造業や卸売業のような複雑な受発注業務には、専用のERPや受発注管理システムが必要です。HubSpotはあくまで「顧客接点のハブ」として、受発注の進捗を営業が把握するための「窓口」として活用するのが適切な位置づけです。
CRM × 受発注管理の連携は、以下のステップで段階的に構築していくのが現実的です。
まずは「受注データと発注データを同じ画面で確認できる状態」を最初のゴールとして設定し、そこから段階的に自動化を進めていただければなと思います。営業とバックオフィスの情報分断が解消されるだけでも、顧客対応のスピードと経営判断の精度は大きく向上します。
関連記事もぜひご覧ください。
月間の取引件数が100件以下で、発注パターンがシンプル(外注費の管理中心)であれば、CRMのカスタムオブジェクトで十分対応できます。一方、在庫管理やロット管理が必要な場合、月間取引件数が数百件を超える場合は、専用の受発注管理システムやERPとの連携を検討すべきです。
Enterpriseプランでは最大10個のカスタムオブジェクトを作成できます。受発注管理では「発注」と「納品」で2個を使用するのが一般的です。残りの枠は、請求管理や在庫管理など、将来的な拡張に使えます。
Salesforceにはより高度なCPQ(Configure, Price, Quote)やERP連携の仕組みがあり、大規模なBtoB企業の複雑な受発注管理に対応できます。HubSpotはその点ではシンプルですが、カスタムオブジェクトとワークフローの組み合わせで中小企業の受発注管理には十分に対応できます。Salesforce経験者の方は、カスタムオブジェクトの考え方がSalesforceのカスタムオブジェクトとほぼ同じですので、スムーズに移行できるかなと思います。
はい、カスタムオブジェクトで「発注」レコードを作成し、会社オブジェクトを「顧客」と「仕入先/外注先」の両方の役割で使うことで管理可能です。取引区分プロパティで「顧客」「仕入先」を区別し、ビューでフィルタリングする設計が実務的です。