卸売業のDXは、受発注・在庫・商流の情報の流れを整理することから始めます。注文から請求までのどこで人が台帳を確認し直しているかを特定し、その箇所から仕組みに置き換えます。
「FAXの注文を入力し直している」「在庫を確認するたびに倉庫へ連絡している」「得意先別の価格が担当者のExcelにしかない」——こうした状態では、注文が入ってから出荷可否を答えるまでに、複数の人と台帳を経由します。
卸売業DXとは、得意先からの受注、仕入先への発注、在庫、出荷、請求に関わる情報の流れを整理し、業務と判断を支える仕組みに変えることです。システムの導入順を決める前に、どこで情報が途切れているかを把握します。関連するトピックを横断的にまとめた部門別DX実践ガイドもあわせてご覧ください。
この記事でわかること
卸売業の受発注や在庫管理の見直しを検討している経営者・業務改善担当者に向けて、業務をつなぐ順序を整理します。
- 着手領域の選び方 — 受発注・在庫・商流のどこで情報が途切れているかを見分けます。
- 受発注の移行方法 — FAXとWeb受注を併用しながら、転記の発生箇所を減らす手順を示します。
- 在庫と商流のつなぎ方 — WMS、販売管理システム、CRMに持たせる情報を整理します。
- 段階的な進め方 — 小さく試した結果をもとに、対象の得意先や業務を広げる判断を説明します。
卸売業のDXで先に見直したい業務の分断
卸売業では、得意先、仕入先、倉庫、営業がそれぞれ異なる情報を使って仕事を進めます。担当者が確認や転記で間をつないでいる場合、システムを追加しても同じ作業が残ります。まず、注文を受けてから請求するまでに、誰がどの情報を受け渡しているかを追います。
受発注で起きる転記と確認
FAXや電話の注文を販売管理システムへ入力し直すと、注文内容の読み取りと入力内容の照合が必要になります。
- 価格表が別のExcelにある場合 ── 品目と数量だけでなく、適用する取引条件も確認しなければなりません。
- 見るべき範囲 ── 注文の入口だけではなく、受注データが出荷指示へ渡るまでの経路です。
受発注業務の課題は次のように整理できます。発生頻度は例示であり、自社の実測値ではありません。優先順位を決める際は、実際の転記件数、訂正の内容、確認に関わる担当者を記録してください。
| 課題 |
影響 |
発生頻度 |
| FAX受注の手入力(転記) |
入力ミスによる誤出荷・返品 |
毎日 |
| 電話注文の聞き間違い |
クレーム・信頼低下 |
週数回 |
| 得意先ごとの価格表管理 |
価格ミスによる利益損失 |
月数回 |
| 発注書のExcel手作成 |
作成・確認に時間がかかる |
毎日 |
| 受注〜出荷指示の連携 |
タイムラグによる出荷遅延 |
週数回 |
在庫と取引条件で起きる属人化
在庫数量を倉庫へ問い合わせないと答えられない状態では、営業が得意先へ返答するまでに待ち時間が生じます。
- 記録の遅れ ── 在庫の画面があっても、入出庫の記録が遅れていれば、その数値で受注を判断できません。
- 画面の導入前に確認すること ── 在庫がいつ更新され、引当済みの数量を誰が判断しているかを確認します。
仕入先のリードタイムや得意先の掛率が個人の台帳に分かれている場合は、異動や引き継ぎの際にも確認が必要になります。担当者の記憶に頼る項目を洗い出し、参照元と更新担当者を決めることが、業務を引き継げる仕組みにつながります。
受注から請求までをどう設計するか
本記事では、受発注、在庫、商流を別々の導入案件として扱わず、受注から請求までの情報の流れとして整理します。
それぞれのシステムが何を正として管理するかを先に決めると、同じ情報を複数の画面で直す作業を減らせます。入口から出口まで、更新の責任を順にたどってみてください。
注文と在庫の情報が合流する場所を決める
Web受注を導入しても、受注内容を紙に印刷して販売管理システムへ入力するなら、転記は残ります。注文データがどの形式で渡され、得意先、商品、数量、価格をどこで照合するかを確認します。
- 販売管理システムへ取り込める場合 ── 連携を検討します。
- 取り込めない場合 ── まず、手入力が残る項目と理由を記録します。
在庫についても、WMSの数量と販売管理システムの受注残を別々に見るだけでは、出荷可能数を判断しにくくなります。
- 引当の時点 ── どの時点で在庫を引き当てるかを決めます。
- 数量を戻す担当と手順 ── 受注変更や返品があった際の担当と手順を明らかにします。
CRMに持たせる役割を分ける
CRMは得意先と仕入先の会社情報、担当者、商談、対応履歴を共有し、営業プロセスを見えるようにする基盤です。
- CRMに持たせるもの ── 顧客情報を保存するだけで終わらせず、誰がどの条件で提案し、その後に何が受注へ進んだかを追えるように設計します。
- 別のシステムと分けるもの ── 在庫数量や請求の確定情報は、それぞれの業務を管理するシステムとの役割分担を決めます。
HubSpotでは会社とコンタクト、取引などのレコードを関連付け、関係する情報をたどれます(出典:レコードを関連付ける)。卸売業で使う場合は、次のように設計します。
- コンタクト ── 得意先の担当者を置きます。
- 取引 ── 提案や契約に向けた進行を置きます。
- 受注後の情報 ── 販売管理や請求の仕組みへどう渡すかまで設計します。
関連付けだけで、得意先別の価格適用や請求処理が自動化されるわけではありません。
受発注管理を段階的にデジタル化する
FAXを一斉にやめる前提で計画を立てると、得意先ごとの発注方法の違いを吸収しにくくなります。
- 対象を決める ── 転記や確認が多い注文を特定し、Web発注への移行を試す対象を決めます。
- 経路を判別できるようにする ── 併用期間中も、どちらの経路から来た注文かを判別できる状態にします。
Web発注へ移す得意先を選ぶ
BtoB受発注システムの候補には、CO-NECT、Bカート、アラジンECなどがあります。製品を比較する前に、対象の得意先がどの商品をどの単位で発注し、価格や納品先をどう指定しているかを整理してください。
同じ注文を繰り返し、商品や条件を事前に整理できる得意先から試すと、Web発注と従来の注文を照合しやすくなります。
得意先側の運用をすぐに変えられない場合は、FAXを受け付けながら、自社内での入力と確認の手順を統一します。WebとFAXを併用する間は次を決めておきます。
- 注文の重複を見分ける項目 ── 重複を見分けるための項目を定めます。
- 訂正時の更新先 ── 訂正が入った際にどちらのデータを更新するかを決めます。
価格と受注データの受け渡しを確かめる
得意先別の価格や掛率は、契約条件、商品、適用時期が一致して初めて注文に使えます。
- 価格テーブルの登録前 ── 現在の表から重複する条件と更新日が不明な条件を分けます。
- 適用の順序 ── 条件が確定した商品から適用し、判断に迷う注文は担当者が確認する経路を残します。
次に、受注システムから販売管理システムへ渡せる項目を照合します。
- 商品コードや得意先コードが一致する場合 ── 連携対象に進めます。
- 一致しない場合 ── 対応表を整え、受注、出荷指示、納品書、請求のどこで変換が必要かを記録します。
API連携の有無だけで判断せず、訂正やキャンセルが起きた際の処理まで含めて確認してください。
在庫管理は記録の時点から見直す
在庫を見えるようにするには、倉庫で起きた入出庫が判断に使う数量へ反映される必要があります。WMSを導入する場合も、現在の記録と実物が合わない理由を把握するところから始めます。在庫確認の電話が減るかどうかは、営業が見る数量の意味を説明できるかに左右されます。
入出庫の記録方法を揃える
バーコードやQRコードを使った入出庫の記録を出発点とします。ロジザードZEROやロジクラなどのクラウドWMSを検討する際は、次を確認します。
- 整理する単位 ── 商品、倉庫、ロットを現在どの単位で管理しているかを整理します。
- 販売や出荷の単位と異なる場合 ── 換算の手順と責任者を決めてから試します。
入庫、出庫、返品、移動のうち、記録が後回しになりやすい処理を確認してください。
- 記録の遅れがある場合 ── ダッシュボードを整える前に、現場で入力できる時点と方法を見直します。
- 記録が揃ってから ── 営業に見せる在庫情報の範囲を決めます。
受注可否に使う数量を定義する
倉庫内の数量と、得意先への出荷を約束できる数量は同じとは限りません。
- 扱いを確認するもの ── 受注済みの引当、出荷待ち、返品の検品待ちをどう扱うかを確認します。
- 差が生じる場合 ── WMSと販売管理システムのどちらが引当を管理し、営業にはどの数量を表示するかを決めます。
需要予測や自動発注へ進むのは、その後です。出荷履歴と仕入条件が整理できていれば、季節変動や得意先ごとの発注傾向を検討できます。
記録の欠落や例外処理が多い間は、自動発注の前に人が確認する対象を定め、判断結果を残す運用から始めることをおすすめします。
商流管理をCRMで共有する
卸売業では、販売先と仕入先の両方について、担当者、条件、対応履歴を参照します。Excelのファイルが部門ごとに分かれていると、同じ会社の情報でも更新の時点が揃いません。CRMへ集める際は項目を増やす前に、日々の判断に使う情報を選びます。
得意先と仕入先の関係を表す
- 得意先情報 ── 担当者、掛率、支払条件、納品条件が含まれます。
- 仕入先情報 ── 仕入条件、リードタイム、最小発注単位が含まれます。
これらを同じ自由記述欄に詰め込まず、会社に共通する情報と、商品や取引ごとに変わる条件を分けてください。条件が変わるたびに履歴を追う必要があるなら、どの単位を別のレコードとして持つかを検討します。
HubSpotのカスタムオブジェクトは、標準のオブジェクトでは表しにくい業務固有の情報を管理する選択肢です。作成にはEnterpriseサブスクリプションが必要と案内されています(出典:カスタムオブジェクトを作成・編集する)。
商品別の取引条件などを独立して管理したい場合は、先に必要な関連と更新手順を描き、標準の会社や取引で扱える範囲を確かめてから採用を判断します。
営業の進行と対応履歴を残す
新商品の提案、増量交渉、価格改定交渉は、受注そのものとは異なる進行を持ちます。
- CRMの取引を使うなら ── 何をもって次の段階へ進むのかを営業チームで定義し、必要な入力項目を絞ります。
- ステージだけを増やさない ── 判断材料が記録されなければ引き継ぎには使えません。
- クレームや返品、品質に関する連絡 ── 担当者個人のメールだけに残さず、関係する得意先や取引から参照できるようにします。
Excel管理からCRMへの移行も参照してください。
以下の画面は、HubSpotの会社レコードにfreee取引先との連携カードを表示した例です。取引先情報をCRMから参照する画面の例として、情報の置き場所を検討する際に見てください。

導入は業務の可視化から広げる
最初から受発注、WMS、CRMを同時に切り替えると、問題が起きた際に原因を追いにくくなります。各段階で次へ進む条件を決めます。
期間を先に固定するより、データと業務の受け渡しが成立しているかを見て進めます。
現状の流れとデータを揃える
受注、在庫確認、出荷、請求の担当者に、使う台帳と入力先を順に確認します。
- 名称が表ごとに異なる場合 ── 同じ得意先名や商品名が複数の表で異なっていれば、まず識別するための項目を揃えます。
- 記録する箇所 ── 転記が生じる箇所と、確認のために業務が止まる箇所を記録すると、先に着手する領域を選べます。
CRMへの集約では、すべての過去情報を一度に移す前に、現在取引している得意先・仕入先の担当者と条件を点検します。
- 更新担当が決まっていない項目 ── 移行後にも古くなります。
- 対象を広げる前に ── 更新担当者と確認のきっかけを決めてください。
小さく試し、連携の範囲を広げる
Web受注は対象を絞って試し、受注データが販売管理システムへ渡るか、訂正を処理できるかを確認します。
- 通る注文と止まる注文の違いが説明できる場合 ── 次の得意先へ広げる判断材料になります。
- 説明できない場合 ── 商品コードや価格条件の整備へ戻ります。
在庫も、対象の商品と倉庫を絞って入出庫を記録し、営業が参照する数量と実際の処理を照合します。その後に、受注時の引当やデータを使った提案へ進みます。得意先ごとの購買傾向を営業に渡す際は、どの提案に使い、反応をどこへ記録するかまで決めます。営業DXの進め方も参考にしてください。
導入前に決めておきたい運用上の分かれ目
卸売業の業務は取引先の注文方法や既存の販売管理システムに影響されます。自社だけの画面を整えても、取引先との受け渡しが途切れれば手作業は残ります。例外が起きたときにどの業務へ戻るかを、導入前に決めておきます。
得意先がWeb発注を使わない場合
Web発注を使える得意先と、FAXを続ける得意先を分けて管理します。
- 移行を依頼する前に ── 相手が必要とする商品一覧、価格、納品先の指定方法を確認してください。
- 条件をシステム上で表せない場合 ── 無理に移行せず、条件の整理か運用の見直しへ戻ります。
併用中は、受注を一度だけ登録するための識別方法と、訂正の連絡先を決めます。
得意先の注文方法が異なっても、社内の出荷指示へ渡るデータの形式を揃えることが、次の連携につながります。
既存システムと接続できない場合
CRM、受発注システム、WMSを個別に導入する場合は、販売管理システムとのデータの受け渡しを確認します。
- APIで連携できる項目が足りない場合 ── ファイルの取り込みや運用上の受け渡しも含めて、手入力が残る場所を明示します。
- 判断の軸 ── 接続方法だけでなく、注文の変更や返品が各システムにどう反映されるかで判断してください。
全体を一度に置き換える必要があるかは、既存システムで扱える業務を確かめてから決めます。連携後も同じ情報を複数の画面で修正するなら、システムの組み合わせより先に、更新元と担当者の定義へ戻るのがよいと考えています。
HubSpotで得意先の発注間隔と商談を管理する設定例
卸売業では、得意先からの定期的な発注が止まったことに気づくのが遅れると、競合への切り替えを防げません。ここでは、HubSpotで得意先ごとの発注状況を記録し、変化に営業が気づける仕組みの設定例を示します。項目名は例なので、自社の言葉に合わせて変えてください。
得意先の発注状況を記録する項目
設定(歯車アイコン)の「データ管理」>「オブジェクト」で会社を選び、次のプロパティを作成します(出典:プロパティの作成と編集)。受発注システムから日付や区分を連携できる場合は、手入力を避けて連携で更新します。
| プロパティ名(例) |
入力形式 |
使いどころ |
| 最終発注日 |
日付 |
一定期間発注がない得意先を一覧で抽出する |
| 通常の発注間隔 |
ドロップダウン選択(週次・月次・季節・不定期) |
間隔に応じて「止まった」とみなす日数を変える |
| 価格区分 |
ドロップダウン選択(標準・特別価格・個別見積) |
特別価格の得意先は改定時に営業が個別に連絡する |
| 主な取扱カテゴリ |
複数チェックボックス |
新商品の案内先を取扱カテゴリで絞り込む |
発注が止まった得意先に気づく自動化
ワークフローで、最終発注日から一定日数が過ぎた得意先に営業担当者のタスクを作ります(出典:ワークフローの作成)。
- 対象を決める ── 会社ベースのワークフローを作り、通常の発注間隔が「月次」の得意先を対象にします。
- 条件を決める ── 最終発注日が45日以上前になったら、という条件を設定します。日数は自社の実績から決めます。
- 動作を決める ── 担当営業に「状況確認」のタスクを作り、確認結果を会社の記録に残すよう求めます。
- 見直す ── 1か月運用し、不要なタスクが多い場合は日数や対象の区分を調整します。
商談として追う案件(新規の得意先開拓や取扱商品の拡大)は、取引のパイプラインで管理します(出典:オブジェクトのパイプラインの設定と管理)。定期発注そのものを取引として毎回作ると件数が膨らむため、発注の記録は会社の項目や連携データで持つのが扱いやすくなります。
よくある失敗と回避策
- 得意先別の価格表をCRMに丸ごと持ち込む ── 価格の正本は販売管理・基幹システムに残し、CRMには価格区分だけを持たせます。
- 発注のたびに取引を作る ── 件数が膨らみ、営業が追うべき商談が埋もれます。定期発注は会社の項目で管理します。
- 通知の条件を全得意先で同じにする ── 発注間隔の違う得意先に同じ日数を当てると、不要な通知が増えます。
自社の状況に合わせた進め方
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わってきました。卸売業のDXでは、次の順で小さく始めて広げる進め方を提案しています。詳しくはHubSpot導入・構築支援で紹介しています。
- 現状の整理・要件定義 ── 受注経路、価格の決め方、在庫確認の流れを棚卸しし、人が判断している箇所を特定します。
- 設計・構築 ── 得意先の項目、発注停止を検知するワークフロー、商談のパイプラインを設計します。
- データ移行 ── 得意先名簿と担当者の台帳を取り込み、表記揺れを整えます。手順はExcel・スプレッドシートからHubSpotへ移行する方法が参考になります。
- テスト・検証 ── 一部の営業担当で運用し、通知の日数と記録の負担を確かめます。
- 定着・運用改善 ── 準委任で伴走しながら対象を広げ、AI(Breeze・Claude等)による発注傾向の要約や問い合わせ対応へ進みます。
請求・入金を会計ソフトで管理している場合は、自社開発の連携アプリSync for freeeで、HubSpotとfreeeの情報をつなぐ方法もあります。ECで受注を受ける場合の設計はBtoB ECとはで解説しています。
| 自社の状況 |
最初の一手 |
広げる条件 |
| 得意先の情報が営業担当者ごとの台帳にある |
得意先名簿をCRMに集め、担当と価格区分をそろえる |
担当不在時も他の営業が得意先の状況を答えられる |
| 発注が止まったことに気づくのが遅い |
最終発注日と発注間隔の項目、通知のワークフローを作る |
通知から状況確認までが定着した |
| FAX・電話の注文の入力に時間がかかる |
注文の多い得意先からWeb受発注を案内する |
案内先の注文の半数以上がWebに移った |
| 在庫の問い合わせに倉庫へ確認している |
在庫の正本を決め、営業が参照できる経路を用意する |
在庫の確認を営業が自分で行える |
よくある質問
卸売業のDXは何から始めるべきですか?
受注から請求までの流れを描き、転記と確認が発生する場所を記録するところから始めてください。得意先や仕入先の条件が個人の台帳に分かれているなら、現在使っている情報をCRMへ集める準備が有効です。対象を絞り、更新担当者まで決めてから移します。
FAX受注をやめる必要がありますか?
得意先の注文方法に応じて、FAXとWeb発注を併用しながら進められます。併用中は注文の重複、訂正、社内での入力先を定めてください。Web発注の対象を広げる際は、転記が減ったかに加え、出荷指示まで情報が渡っているかを確かめます。
中小規模の卸売業でも取り組めますか?
対象の業務や得意先を絞って始められます。人手で行う転記や在庫確認がどこにあるかを把握し、その作業を減らせる範囲から試してください。導入後に別の画面への再入力が増えるなら、連携方法と項目の設計を見直します。
既存の販売管理システムは入れ替えるべきですか?
まず、受注、在庫、請求に必要な情報をどの方法で受け渡せるかを調べます。必要な項目と変更処理を扱えるなら、既存システムを使いながら周辺業務を整える選択肢があります。扱えない業務が明確になった時点で、その部分の変更範囲を検討します。
まとめ
卸売業のDXでは、受発注、在庫、商流をつなぐ情報の流れが重要です。Web受注、WMS、CRMを検討する際も、注文の訂正や在庫の引当、取引条件の更新を誰がどこで行うかまで決めてください。担当者の記憶や個別のExcelに頼っている判断を共有できる形にすると、引き継ぎにも使える業務設計になります。
まずは、受注から請求までの転記箇所を記録するところから始めてください。
- 注文、在庫確認、出荷、請求で使っている台帳と担当者を書き出します。
- 同じ情報を入力し直している場所を選び、元になるデータと更新担当者を決めます。
- 対象の得意先や商品を絞って試し、次へ進めるか、項目や手順へ戻るかを判断します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい