CRMと受発注管理の連携設計ガイド｜BtoB取引をデジタル化する方法

CRMと受発注管理をつなぐには、受注後の業務まで含めて、誰が何を確定し、次の担当者へ渡すかを決める必要があります。連携の核心は、受注から請求までの判断と情報の流れをそろえることです。

「受注はCRMに登録しているのに、発注は別のExcelで管理している」「営業からバックオフィスへの連絡がメールやチャットに散らばる」「顧客に納期を聞かれても、その場で状況を答えられない」——こうした分断があると、担当者は案件の現在地を確かめるために複数の記録を照合しなければなりません。

CRMと受発注管理の連携とは、CRMにある顧客・商談データと、見積、受注、発注、納品、検収、請求の業務データを、一つの案件からたどれるように設計することです。この記事では、業務の接続点を決め、データの管理責任を分け、実際の案件で動作を確かめるまでの順序を示します。

本記事は「CRMを起点としたバックオフィス統合の設計思想｜フロントとバックをつなぐ事業基盤」シリーズの一部です。

この記事でわかること

BtoBの受発注プロセスとCRMが分断されており、営業からバックオフィスまで案件の状況を追えるようにしたい経営者・営業マネージャー・業務改善担当者の方に向けた内容です。

• CRMと受発注管理を連携する目的 — 受注後の伝達と進捗確認で何が必要かを整理し、連携対象を決める視点を得られます。
• 統合データモデルの設計方法 — 会社、コンタクト、取引、発注、納品を関連付け、情報の更新元を決める手順を確認できます。
• HubSpotでの実装と外部連携の使い分け — カスタムオブジェクト、ワークフロー、ダッシュボード、iPaaSやAPIを、業務上の役割から選べます。
• 失敗を避ける段階的な導入手順 — 主要な受発注パターンで何を確認してから自動化や対象範囲を広げるかを判断できます。

まず自社の案件を一つ選び、受注から請求まで、誰がどの記録を見て次の処理へ進むかを追いながら読むと、設計が必要な箇所を見つけやすくなります。通常どおり進んだ案件に加え、受注条件が途中で変わった案件も確認すると、更新元や差し戻しの決め方が明確になります。

どこまでCRMで扱うかは、次の表で自社の状況に当てはめて選べます。

CRMと受発注管理を連携する目的

CRMは顧客情報に加え、商談の条件や担当者とのやり取りを確認する場所になります。一方、発注、在庫、納品などの実処理には、それぞれの担当者と管理方法があります。連携の目的は、すべてを同じ画面で処理することではなく、案件を引き継ぐ際に必要な情報を欠かさず渡し、状況を確かめられるようにすることです。

Excelとメールに分かれた受注後の業務

営業がCRMで受注を記録した後、案件名や金額、納期をExcelへ転記し、メールやチャットで事務担当へ連絡する運用では、同じ情報が複数の場所に生まれます。条件が変わったときに更新先が決まっていなければ、担当者ごとに異なる内容を参照する可能性があります。

最初に、受注情報を受け取る担当者へ「何を見れば発注準備を始められるか」を確認します。

• 取引の金額だけでは足りない場合 ── 発注先や納期も必要なら、それぞれの入力者と確定する段階を決めます
• 入力できない情報が残る場合 ── 発注を自動で進めず、確認する担当者へ戻す流れにします

受け取る側が資料を探さずに着手できるかが、次の設計へ進む判断基準です。

表の各行について、現在の記録場所、更新する人、次に受け取る人を埋めます。そのうえで、転記をなくせば解決する箇所と、担当者による判断が必要な箇所を分けます。後者は通知だけを自動化しても解決しないため、判断に使う情報と確認者を先に定めます。

顧客対応を受注後までつなげる

営業が顧客から納期を聞かれたとき、発注や納品の進捗がCRMから見えなければ、バックオフィスへ確認してから回答することになります。取引と発注・納品レコードを関連付ける際は、営業が知りたい情報を先に定めます。例えば、予定の納期と確定した納期を混同しないよう、どちらを表示するか、誰が更新するかを決めます。

顧客へ回答する前に担当者の確認が必要な状態なら、CRM上にもその状態が分かるようにします。営業が参照する概要と、バックオフィスが行う詳細な発注処理を分けることで、画面の情報だけで回答してよい場面と、確認してから回答する場面を区別できます。

CRMを事業の流れとして捉える

受発注連携は、受注レコードを別システムへ渡すだけでは完結しません。コンタクトと会社から始まり、取引、発注、納品、検収、請求へ進み、必要な結果が取引へ戻る流れとして捉えます。

この流れを設計するときは、各段階で「次の担当者が処理を始められる状態」を定義します。

• 発注 ── 作成されても発注先を決められなければ、発注準備は完了していません
• 検収 ── 記録があっても請求条件を確認できなければ、経理へ渡す前に確認が必要です

レコードの有無と、業務を進められる状態を分けて確認します。案件を逆方向にもたどり、請求担当者が元の検収結果と受注条件を確認できれば、引き継ぎに必要な関連付けを検証できます。

BtoB受発注をデジタル化する業務効果

受発注のデジタル化では、紙やExcelを別の入力画面へ置き換えるだけでなく、入力した情報が次の担当者の判断に使われる状態を目指します。効果を検討するときは、転記の回数を想像するより、案件を追った際に確認待ちや入力し直しがどこで起きるかを見ます。

導入前後で同じ種類の案件を追い、次の項目を比べると、改善した工程と残った工程を区別できます。

• 確認のために開いた記録
• 担当者への問い合わせ
• 差し戻しの理由

転記と伝達を仕組みに置き換える

手作業では、受注情報を読んだ担当者が発注書を作り、別の担当者へ作業を依頼します。連携後は、事前に定めた取引ステージを起点に発注レコードを作り、購買担当へタスクを割り当てる流れを設計できます。

受注条件の変更があり得るなら、どの情報を発注レコードへ引き継ぎ、変更後は誰が修正するかを決めます。起票後に条件が変わった案件を追い、元の取引と発注の内容が食い違わないことを確認してから対象を広げます。

漏れが起きたときは、担当者への注意だけで済ませず、起票条件、担当者、完了条件のどこに不足があったかを調べます。

• 発注レコードが作られていない ── 起点と入力条件を確認します
• 作られていても着手されていない ── 割り当て先と通知を確認します
• 着手後に止まる ── 判断材料を確認します

原因に応じた修正を行い、同じ種類の案件で再び処理を追います。

営業とバックオフィスが同じ案件を見る

営業とバックオフィスで管理画面が異なっても、共通の案件IDや関連付けを使えば、同じ受注案件を基準に会話できます。営業は取引レコードから発注や納品の概要を確認し、バックオフィスは元になった受注条件へ戻れます。

以下の画面は、HubSpotの取引レコード詳細に請求情報とfreee連携カードが表示されている状態です。

画面上に関連情報が表示されても、必要な案件へ正しく結び付いていなければ判断には使えません。受注案件から発注と納品をたどり、逆に発注から元の取引へ戻れるかを確認します。

• 紐付けられない記録が見つかったら ── 表示項目を増やす前に、案件を特定する方法を見直します
• 似た名称の案件がある場合 ── 名称だけに頼らず、どの記録を根拠に関連先を選ぶかを決めます

案件単位で受注と発注を捉える

受注データと発注データが別々に集計されていると、外注費や仕入れがどの案件で発生したのか追いにくくなります。取引と発注を関連付ければ、受注金額と発注金額を案件単位で比較する土台になります。

比較する前に、複数の発注をどの取引へ集めるか、発注金額の変更をいつ反映するかを決めます。数値が食い違ったときに参照すべき正式な記録も明確にします。

比較結果が想定と違う案件では、次の順に確認します。

1. 関連付けの漏れ
2. 変更の反映待ち
3. 扱う金額の意味の違い

原因を説明できる状態になってから、集計を判断に使います。

受発注とCRMを統合する設計フレームワーク

連携ツールを選ぶ前に、業務フロー、データモデル、ステータス、入力項目を順番に設計します。順序を飛ばすと、部門ごとに異なる「受注」「発注済み」「検収完了」の意味が、そのまま連携条件に入り込みます。各段階で判断に使う事実と、次へ渡す情報を確定させます。

全体フローと接続点を決める

全体フローは、営業プロセスと受注後の業務プロセスを横に並べて整理します。

まず、受注から発注処理へ渡す条件を決めます。

1. 受注の意味をそろえる ── 「受注」と記録する人によって意味が違うなら、契約内容の確認など、自社で受注を確定する事実をそろえます
2. 確定している情報を確認する ── その時点で発注先、金額、納期のうち何が確定しているかを確認します
3. 起票のタイミングを選ぶ ── 未確定の情報があれば、発注を起票して担当者の確認を待つのか、確定後に起票するのかを選びます

選択の基準は、未確定のまま作った記録が次の担当者にとって有用かどうかです。

• 確認待ちの状態を明示して起票する ── 購買担当が不足項目を確認しながら準備できる場合です
• 確定を待って起票する ── 発注先や条件が決まるまで着手できず、仮の記録が誤発注につながる場合です

いずれの場合も、条件変更時に誰が発注内容を見直すかを決めます。

検収から請求へ渡す際も同じです。納品した事実と、顧客による検収が完了した事実を区別し、請求担当者へ渡す条件を明文化します。受注や検収の判定が担当者ごとに異なる場合は、自動化より先にステージ定義をそろえます。検収結果を示す記録が見つからない案件では請求タスクを進めず、記録の担当者と確認経路を決めてから接続します。

オブジェクトと関連付けを設計する

CRMでは、情報の種類ごとにオブジェクトを分け、レコード同士を関連付けます。受発注管理では、会社、コンタクト、取引に加えて、必要に応じて発注と納品をカスタムオブジェクトとして表現します。

一つの取引に複数の発注を関連付ければ、同じ受注案件に外注先への発注と仕入先への発注がある構造を表せます。発注ごとに金額や納期が異なるなら、取引の一項目へまとめず、個別の記録として扱うかを検討します。

設計後は、実際の案件を使い、取引からすべての発注を見つけられるか、発注から元の取引と発注先へ戻れるかを確かめます。

• どの取引にも結び付かない発注がある場合 ── レコード作成時に関連取引を決める手順を追加します
• 複数の取引へ結び付ける必要が生じた場合 ── どの案件の金額や進捗に含めるかを先に決め、集計上の扱いを確認します

パイプラインを四つの要素で定義する

受注と発注の進捗は、ステージ名だけを並べても運用できません。ステージ、確度、ステージ定義、ステージ移行時の必須プロパティを組み合わせて設計します。

例えば、契約締結を発注起票の条件にするなら、「契約締結」と判断する事実、入力を終える項目、確認する担当者を一緒に決めます。担当者がステージを変更するだけで発注してよいのか、購買担当による確認を挟むのかが分かれ目です。判断に迷う案件が残る間は、ステージ変更を通知や確認タスクの起点にとどめ、起票条件を見直します。

定義を確かめる際は、担当者の違う案件を並べ、同じ事実なら同じステージへ進むかを確認します。異なる判断が出たら、ステージ名を増やす前に、判断に使った事実と不足していた項目を比較します。担当者が根拠を確認できる定義になってから、そのステージを自動処理の起点にします。

項目は判断と引き継ぎに使うものへ絞る

発注番号、発注先、発注金額、発注日、納期、ステータス、関連取引は、発注管理の基本項目として整理できます。ただし、すべてをレコード作成時に必須にすると、その段階では決まっていない情報まで仮入力する運用になりかねません。

項目ごとに「誰が」「どの段階で」入力し、「次の担当者が何を判断するために」使うかを決めます。発注準備で必要な項目と、発注確定後に記録する項目を分けます。運用中に空欄が続く項目は、入力を促す前に、その段階で確定できる情報かを確認します。

• 空欄でも次の処理に進める項目 ── 後の段階へ移します
• 空欄では進めない項目 ── 確認担当者と差し戻し先を明確にします

HubSpotで受発注管理を実装する方法

HubSpotでは、取引を受注案件として使い、発注や納品をカスタムオブジェクトで表現する構成を検討できます。ワークフローは定義済みの条件に沿った起票や通知、ダッシュボードは担当者の判断に必要な状況の表示に使います。実装範囲は、実際の受発注パターンと利用環境を確認して決めます。

カスタムオブジェクトで発注を表現する

（出典：Schemas API guide）

発注オブジェクトでは、発注番号をレコードの識別に使い、発注先の会社と元になった取引を関連付けます。納品を独立して管理する場合は納品オブジェクトを設け、関連する発注と取引をたどれる構造にします。

発注と納品を分けるかは、管理したい状態で判断します。

• 納品ごとに日付や検収状況を追う必要がある場合 ── 発注とは別に記録する構成を検討します
• 発注の進捗だけで担当者の判断が済む場合 ── まず必要な情報を絞って設計し、案件を追う中で不足するか確かめます

分けた場合は、発注から納品へ、納品から元の取引へ戻れることも確認します。

HubSpotの画面で発注オブジェクトと起票を設定する手順

メニュー名は公式ナレッジ（カスタムオブジェクトの作成、ワークフローの作成）で確認したものです。カスタムオブジェクトの作成・編集には「アカウントアクセス」権限が必要で、Enterprise が対象です。

1. 「データ管理（Data Management）」の「データモデル（Data Model）」を開き、「データモデルを編集（Edit data model）」を選びます。左パネルの「すべてのオブジェクト」の横の「+」から「カスタムオブジェクト（Custom object）」を選びます。
2. オブジェクト名（単数形・複数形）を入力します。日本語では、どちらも「発注」で構いません。名前はHubSpotの既定のオブジェクト名と同じにできません。
3. 「プライマリ表示プロパティ（Primary display property）」に「発注番号」を設定し、値の重複を禁止するチェックをオンにします。内部名は作成後に変更できないため、命名規則を先に決めます。
4. 「作成（Create）」を押し、オブジェクトの設定でプロパティ（発注先、発注金額、発注日、納期、ステータス）を追加します。ステータスは「発注準備」「発注確定」「発注済み」「納品済み」「検収完了」のような選択肢にします。
5. データモデルのグラフビューで、取引と会社への関連付けを追加します。発注から元の取引、発注先の会社をたどれる構造にします。
6. 「オートメーション（Automation）」の「ワークフロー（Workflows）」を開き、「ワークフローを作成（Create workflow）」で「最初から（From scratch）」を選びます。取引のステージが「契約締結」になったことをトリガー（フィルターベース）にし、購買担当へのタスク作成（Create task）を追加します。
7. 再登録の可否と登録解除の条件は「設定（Settings）」タブで決めます。テスト用の取引で、ステージを進めたときに発注の起票とタスクが一度だけ作られることを確認します。

ワークフローは Marketing Hub、Sales Hub、Service Hub、Data Hub などの Professional／Enterprise で使えます。Enterprise でない場合は、発注の管理を受発注システム側に任せ、HubSpotの取引には進捗の状況だけを表示する構成を検討します。後から変えにくい設定（内部名、オブジェクト構成）は HubSpotで後から変えにくい設定 で先に確認してください。

ワークフローで受注後の処理をつなぐ

ワークフローには、担当者の代わりに曖昧な条件を判断させるのではなく、定義済みの条件に沿ってレコード、タスク、通知を動かす役割を持たせます。

• 取引が契約締結へ進んだら、発注レコードを作成して購買担当へタスクを割り当てます。
• 納期が近づいた未完了の発注を、購買担当と営業担当へ通知します。
• 納品のステータスが検収完了へ変わったら、経理チームへ請求タスクを作成します。
• 受注金額と発注金額の差額を、取引の粗利確認に使う項目へ反映します。

最初に、各動作の起点、必要な入力、実行後に確認するレコードを対応付けます。その上で、次の順に確かめます。

1. テストする ── テスト用の取引を受注へ進め、発注が重複せず、担当者と関連取引が正しいことを確認します
2. 例外の案件を追う ── 条件を変更した案件、検収前で止まっている案件も追い、意図しない起票や請求タスクがないことを見ます
3. 修正する ── 想定と異なる場合は対象を広げず、起点となるステージや入力条件を修正します

差額を表示する場合は、比較する受注金額と発注金額の意味、更新元、反映される段階をそろえます。複数の発注がある案件で表示と元の記録を照合し、未確定の発注が判断に混ざらないかを確かめてから利用します。

ダッシュボードで役割別に可視化する

ダッシュボードは、利用者が次の行動を決められる単位で分けます。営業には顧客への回答に必要な納品状況、バックオフィスには処理待ちの発注や検収、経営には案件別の受注・発注状況を示します。

表示した情報が実務に使えるかは、会議や問い合わせの場面で確認します。

• 画面を見ても担当者へ聞き直す必要がある場合 ── 足りない情報が何かを特定します
• 元のレコードが更新されていない場合 ── レポートを追加する前に更新の担当者とタイミングを見直します

表示内容から次の行動を決められるようになったら、対象とする案件や利用者を広げます。

外部の受発注管理システムと接続する方法

在庫、ロット、製造指示などの実処理が必要な場合は、その業務を担うシステムとCRMの役割を分けて設計します。CRMは顧客接点と案件状況、ERPや受発注管理システムは発注・在庫などの業務データを担う構成を検討できます。接続方法を選ぶ前に、互いに渡す必要がある情報を確定します。

マスターと同期方向を決める

同じ項目を複数のシステムで編集できる状態にすると、更新の順番によって異なる値が残る可能性があります。項目ごとに正とするシステムと同期方向を決めます。

表を自社の項目へ当てはめる際は、名称が同じでも意味が違う情報を確認します。例えば、CRM上の予定納期と業務システム上の確定納期は、どちらも「納期」とだけ表示すると誤解を招きます。

• 意味と更新元が異なる場合 ── 表示上も区別します
• 双方向更新が必要な項目 ── 競合した場合の優先順位と修正担当者を決めてから扱います

同期の設計後は、業務システム側で納期が変更された案件を追い、CRMで何が表示され、営業がどの状態なら顧客へ回答できるかを確認します。変更が届かない場合は、営業の手入力で埋める前に、元の記録、連携の状態、確認担当者を調べます。

iPaaSとAPIを使い分ける

連携方法は、扱うデータ、処理条件、既存システムの接続方法によって選びます。まず、次の項目を整理します。

• 送る情報
• 受け取る情報
• 連携の起点
• 失敗時に確認する担当者

既存の接続方法で条件を表現できるかを確認し、足りない処理がある場合に別の方法を検討します。

在庫引当のように業務システム側の判断結果が必要な処理と、検収完了の情報を請求担当者へ渡す処理では、求める連携が異なります。

• 前者（業務システム側の判断結果が必要な処理） ── 結果をどの時点で確認するかを先に決めます
• 後者（検収完了の情報を渡す処理） ── 二重に依頼を作らないかを先に決めます

接続方法を比較するときは、正常な案件だけでなく、必要項目が欠けた案件、条件が変更された案件、送信結果が分からない案件を同じ手順で扱えるかを確かめます。

日系SaaSとの連携を含む場合は、Yoomも選択肢になります。見積から入金までの全体設計は、Quote-to-Cash設計ガイドで解説しています。

連携エラーを業務フローに含める

連携は正常に動く経路だけでなく、データ不足や接続エラーが起きたときの処理まで設計します。エラーになったレコードを誰が確認し、修正後にどこから再実行し、どの記録を見て完了とするかを決めます。

例えば、次のように扱います。

• 発注先が未入力 ── 発注レコードを外部へ送らず、担当者へ確認を戻します
• 再実行 ── 発注先、関連取引、発注金額がそろった後に行い、送信先にも正しい案件として記録されたことを確認します
• 送信したか分からない場合 ── 再実行の前に送信先を調べ、同じ発注を重複して作らない手順にします

完了の判定は「送信操作をした」ではなく、送信先で対象案件と内容を確認できた状態に置きます。

受発注連携で起きやすい失敗と限界

受発注連携では、データの管理責任や現場の入力ルールが曖昧なまま機能を増やすと、どの記録を信じるべきか分かりにくくなります。二重管理、対象範囲の広げすぎ、入力項目の増やしすぎを、実際の案件を追いながら確認します。

マスターが曖昧なまま同期する

CRMと受発注管理システムの両方に同じ案件情報があり、どちらを正とするか決まっていないと、営業が見る条件とバックオフィスが処理する条件が異なることがあります。

顧客・商談情報はCRM、発注・在庫情報はERPまたは受発注管理システムをマスターとする構成を起点に、自社の役割分担を確認します。

1. 編集者と同期方向を決める ── 項目単位で決めます
2. 条件を変更した案件を追う ── 変更が必要なとき、担当者が正しい記録を更新でき、その結果が参照先へ伝わるなら次へ進めます
3. 伝わらない場合は見直す ── 同期を増やす前に、その項目が確定する段階と連携の起点を見直します

すべての発注パターンを同時に扱う

定型発注、スポット発注、外注、仕入れを同時に設計すると、例外条件の違いを確かめる前に分岐が増えます。まずは、受注から発注、納品、検収、請求まで担当者と記録を追える主要パターンを選びます。

そのパターンで処理を進め、止まった箇所を次のように分けて記録します。

• 情報が足りない
• 担当者が決まらない
• システムで扱う範囲が違う

不足が共通の項目や定義で解消できるなら設計を見直します。別の業務判断が必要なら、次のパターンとして扱うか、専用システム側に残すかを決めます。

入力項目と承認を増やしすぎる

データを細かく取りたいという理由だけで項目を増やすと、入力する段階では確定していない情報まで求めることになります。承認段階を増やす場合も、誰が何を確認するのかが曖昧なら処理の現在地が分かりにくくなります。

必須項目は、次の担当者が処理を始めるための情報と、顧客対応や会議で使う情報を基準に選びます。

• 使われていない項目 ── レポート、ワークフロー、引き継ぎのどこで参照されるかを調べます。用途がなく、次の処理にも影響しないなら入力対象を見直します
• 承認 ── 確認する事実と承認後に進む処理を示せない場合は、その段階の役割を整理します

HubSpotだけでは扱いにくい業務を分ける

HubSpotで発注や納品の記録を取引へ関連付ける構成を検討できます。一方、在庫、ロット、製造指示の実処理を含む業務では、既存のERPや専用の受発注管理システムが担っている処理を確認する必要があります。

• 参照が目的の場合 ── CRMに戻す状態と更新元を決めます
• 実処理が必要な場合 ── 担当システムで完了を判断する条件を定め、その結果のうち顧客対応に必要な情報をCRMへ渡します

企業様によって最適な形は異なります。

境界を決める際は、案件を使って「誰が在庫や製造の判断を確定するか」「営業はその結果の何を見れば回答できるか」を確認します。CRMに表示された状態から実処理の担当者や元の記録をたどれれば、役割分担を検証できます。たどれない場合は、表示を増やす前に関連付けと更新元を見直します。

CRMと受発注連携を段階的に導入する手順

最初は、受注データと発注データを同じ案件から確認できる状態を目標にします。そこで入力者、関連付け、更新の流れを確かめてから、通知、請求への接続、外部システム連携を追加します。各段階で実際の案件を追い、次へ進める条件を確認します。

現状の業務と手作業を可視化する

受注後に誰が何を受け取り、どの記録へ入力し、次の担当者へ何を渡しているかを書き出します。Excel、メール、チャットに同じ項目を転記している箇所と、担当者への確認が発生している箇所を見つけます。

表を埋めたら、一つの案件を受注から請求まで追います。担当者によって異なる答えになる行があれば、その定義や責任者を決めてからデータ構造の設計へ進みます。特に条件変更があった案件では、どこを修正すると次の担当者へ伝わるかも確認します。

受注パイプラインと発注データを整える

CRM上の受注パイプラインについて、ステージ、確度、定義、必須プロパティを整理します。契約締結を発注起票の条件にする場合は、その時点で確定している条件と、購買担当が確認すべき条件を分けます。

発注データは、発注番号、発注先、発注金額、発注日、納期、ステータス、関連取引を中心に、入力する段階を決めます。

• 案件を登録する ── 主要な発注パターンの案件を登録し、発注から元の取引へ戻れること、次の担当者が必要な情報を見つけられることを確認します
• 迷う項目や仮入力が残る場合 ── 必須にする段階を見直します

担当者が元の受注条件と発注内容を照合できるようになってから、自動起票の条件を決めます。

自動化と可視化を追加する

データの入力と更新が回るようになってから、受注時の発注起票、納期前の通知、検収完了時の請求タスクを順に追加します。各動作について、起点となったレコードと作成されたレコードを見比べ、関連先、担当者、内容が正しいかを確認します。

次に、営業、バックオフィス、経営が実際に判断する場面でダッシュボードを使います。

• 必要な情報がCRMにない場合 ── その情報のマスターと更新者を確かめ、外部システムから戻す範囲を決めます
• 誤った通知や古い表示が見つかった場合 ── 対象を広げる前に更新元と連携条件を直します

起票、変更、停止、再実行の各場面で担当者が次の行動を判断できたら、別の発注パターンへ進みます。

受発注連携を進める支援の流れ

StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。受発注の連携では、システムを選ぶ前に、受注から請求までの情報の流れと更新元を整理します。導入全体の進め方は HubSpot導入・構築支援 に掲載しています。

1. 現状の整理・要件定義 ── 受注から請求までの流れを並べ、Excel・メール・チャットへの転記箇所を洗い出します。
2. 設計・構築 ── オブジェクト、関連付け、プロパティ、パイプライン、ワークフロー、ダッシュボードを設計して設定します。
3. データ移行 ── 既存の案件・発注データを移し、件数と関連付けを突き合わせます。
4. テスト・検証 ── 主要な発注パターンと例外（条件変更・複数発注）の案件で、起票と通知が意図どおり動くかを確認します。
5. 定着・運用改善 ── 週次で入力の抜けと停滞を確認し、自動化の範囲を段階的に広げます。

スモールスタートで一つの発注パターンから始め、準委任で伴走します。標準の連携で足りない会計との連携は、自社開発の Sync for freee で補えます（HubSpotの取引から見積書・請求書を作成し、取引データをfreee会計に登録できます）。freeeと連携できるCRMの選び方は freeeと連携できるCRMの選び方、請求・入金までの設計は Quote-to-Cash設計ガイド で解説しています。

よくある質問

CRMと受発注管理の境界、発注データの持ち方、連携前に決める事項を整理します。自社の案件で、誰が実処理を行い、誰が状況を参照するかを分けて考える際の判断材料にしてください。

CRMで受発注管理を行うか、専用システムを使うかはどう判断しますか？

まず、営業が案件と発注・納品の進捗を確認したいのか、在庫や製造を含む実処理まで必要なのかを分けます。

• 進捗の確認が目的の場合 ── CRMに発注や納品を関連付ける構成を検討できます
• 実処理まで必要な場合 ── 実処理を担うシステムを確認し、CRMへ戻す情報と更新元を決めます

主要な案件で必要な判断を追い、CRMに表示すべき情報が定まってから構成を選びます。

HubSpotのカスタムオブジェクトで何を管理できますか？

発注や納品など、自社で区別したい情報をレコードとして設計し、取引や会社との関係を表す用途を検討できます。実際に使う構成は利用環境を確認した上で決めます。発注と納品を分けるかは、納品ごとに日付や検収状況を追う必要があるかで判断します。分けた場合は、担当者が発注から納品と検収の記録をたどれるかを確かめます。（出典：Schemas API guide）

一つの受注案件に複数の発注がある場合も管理できますか？

取引と発注を関連付け、発注ごとに記録を分ける構成を検討できます。外注先への発注と仕入先への発注それぞれについて、発注先、金額、納期、ステータスを追います。まず実際の案件で、取引からすべての発注を見つけられるかを確認します。金額を案件単位で比較する場合は、どの発注をその取引へ含めるかも決めます。

外注先への発注管理にも使えますか？

会社に取引区分を持たせ、発注を外注先の会社と元の取引へ関連付ける方法を検討できます。顧客と外注先を同じ会社データで扱う場合は、担当者が区分を見分けられるか、発注先を誤って選ばないかを実際の登録手順で確かめます。誤選択が起きるなら、入力時に参照する区分と確認する担当者を見直します。

連携を始める前に何を決めればよいですか？

次の項目を決めます。

• 受注と検収を確定する事実
• 項目ごとのマスターと入力者
• 同期方向
• エラー時の確認担当者

その後、主要な発注パターンを選び、受注から発注、納品、検収、請求まで一つの案件を追います。次の担当者が必要な情報を確認でき、記録の更新元が明確になってから連携範囲を広げます。条件が変わった案件でも同じ手順で引き継げるかを確認すると、見直すべき箇所を特定できます。

まとめ

CRMと受発注管理の連携では、一つの案件を基準に、受注条件、発注、納品、検収、請求の状況をたどれるようにします。そのためには、各段階で次へ進む条件と情報の更新元を決めることが先です。発注や在庫の実処理を別のシステムが担う場合も、担当者が必要とする情報を案件へ結び付けて確認できるようにします。

まずは同じ案件から受注と発注を見える状態へ

最初のゴールは、受注データと発注データを同じ案件から確認できる状態です。取引と発注を関連付け、営業とバックオフィスが共通の案件を基準に会話できるようにします。

その状態で案件を追い、入力や更新が止まる箇所を確認します。受注の意味がそろっていなければステージ定義を、次の担当者が処理できなければ必要項目と引き継ぎ先を見直します。条件変更後も正しい記録へ戻って確認でき、担当者が次の処理を判断できるようになってから、自動化の範囲を広げます。

自分で進める次の行動

1. 現在の受注から請求までの流れを並べ、Excel、メール、チャットへの転記箇所と、担当者への確認が必要な箇所を特定します。
2. 会社、取引、発注、納品で扱う情報について、どのシステムをマスターにし、誰が更新するかを項目単位で決めます。
3. 主要な発注パターンを選び、取引から発注と納品をたどり、次の担当者が処理を始められるかを確かめます。

この確認ができたら、受注時の起票、納期通知、検収後の請求タスク、外部システム連携を順に検討します。新しい処理を加えるたびに案件の記録を見て、条件が合わなければ定義や更新方法へ戻ります。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Quote-to-Cash設計ガイド｜見積→請求→入金をCRM上で一気通貫管理する方法
• iPaaS / API連携で構築する統合業務基盤｜CRMと業務ツールをつなぐ設計パターン
• CRMとERPの連携設計｜顧客データと経営データを統合する方法
• 入金消込の自動化と売掛金管理｜販売管理と会計をつなぐ入金管理の設計