製造業の営業DX|SFAで受注サイクル短縮の具体プロセス
製造業の営業DX|SFAで受注サイクル短縮の具体プロセス
製造業の営業DXは、SFAを入れれば終わりではありません。DX推進の現場では、承認待ち、二重入力、納期回答の持ち帰りが滞留の三大要因になりやすく、まずは商談から見積、承認、在庫や生産確認、受注、納期回答までを分解し、可視化してから標準化し、
製造業の営業DXは、SFAを入れれば終わりではありません。
DX推進の現場では、承認待ち、二重入力、納期回答の持ち帰りが滞留の三大要因になりやすく、まずは商談から見積、承認、在庫や生産確認、受注、納期回答までを分解し、可視化してから標準化し、そこではじめてSalesforceのようなSFAとERPや販売管理、在庫・生産システムをつなぐ設計が効いてきます。
この記事は、製造業の営業部門、営業企画、情報システム、DX推進担当者に向けて、どの工程をSFAで見える化し、どこを連携や自動化の対象にするべきかを整理するものです。
製造業にSFAが必要な理由とは?導入メリットや選び方・成功事例を解説などで示される予測誤差30%から10%、公開事例ベースの失注率約10%削減、海外事例のOTC14日短縮も踏まえつつ、再現の条件を工程別KPIとあわせて見ていきます。
要するに、最初にやるべきことはツール比較ではなく、まず1か月だけ現状のリードタイムを計測することです。
そのうえで、見積、承認、在庫確認のどれか1工程から着手すると、受注サイクル短縮の打ち手が具体策として見えてきます。
製造業の営業DXとは?SFAが受注サイクル短縮に効く理由

営業DXの定義と対象範囲
営業DXとは、紙やExcelをSFAに置き換えることではありません。
要するに、営業担当者の入力方法だけを変えるのではなく、商談の進め方、見積の作り方、承認の流し方、納期回答の出し方、受注後の引き渡し方まで含めて、営業プロセスと意思決定の流れを再設計することです。
ここでいうSFA(Sales Force Automation)は、案件管理、行動管理、予実管理、商談進捗の可視化を担う営業支援の中核です。
ただし製造業では、案件が前に進むかどうかを左右するのは営業部門の記録だけではなく、価格承認、在庫確認、生産可否、納期回答といった周辺工程です。
そこで本記事では、SFAを起点にしつつ、販売管理やERP、在庫・生産、受発注システムとの連携までを含めて「受注サイクル短縮」を設計対象として扱います。
この定義を最初に置く理由は、営業DX案件の初回打ち合わせで最も多い誤解が「SFAを入れれば名刺情報と案件一覧が見えるようになる」という期待だからです。
実務では、案件一覧が整っても、見積の承認がメール往復で止まり、在庫確認が別システムのままなら、受注までの時間は縮まりません。
DX推進の現場では、SFAそのものより、承認ルートをどう標準化するか、在庫や納期の参照をどこまで自動化するかで成果差が出ます。
営業が入力した案件情報が、その先の見積書作成、受注登録、納期回答に再利用される状態までつながって、はじめて「営業DX」と呼べる段階に入ります。
背景として、古い基幹システムや属人的な運用を放置したときのコストは無視できません。
経済産業省のDXレポートで知られる「2025年の崖」は、既存システムの老朽化や複雑化を放置すると、2025年以降に最大12兆円/年の経済損失が生じうるという問題提起として広く参照されています。
この数値は日本企業全体のマクロ試算であり、製造業だけの損失額ではありませんが、営業・生産・物流が分断されたままでは機会損失が積み上がる、という警鐘としては十分に重い数字です。
加えて、Deloitteの製造業見通しでは、経営層の80%が改善予算の20%以上をスマート製造に振り向ける見通しとされ、PwCの見通しでも、2030年までに主要工程を高度自動化すると見る企業比率が18%から50%へ伸びる方向が示されています。
営業だけが手作業のまま残る構図は、むしろ全体最適の阻害要因になりつつあります。
なお、本記事で扱う定量効果は公開事例ベースです。
業界平均を示す横断統計ではないため、どの工程を変えたのか、どのシステムまで連携したのか、どのKPIで測ったのかという前提をセットで読む必要があります。
この見方を外すと、SFA導入だけで受注率やリードタイムが自然に改善するように見えてしまいますが、実際はプロセス設計とデータ連携の条件が揃っているケースに成果が集中します。
SFA/CRM/MAの違い
営業DXを進めるうえで混同されやすいのが、SFACRMMAの役割です。
通り、SFAは営業活動を前に進めるための運用基盤、CRMは顧客情報や接点履歴を蓄積して関係性を管理する基盤、MAは見込み顧客の獲得や育成を自動化する基盤です。
同じ顧客データを扱っていても、見る対象と判断タイミングが異なります。
製造業の文脈に引きつけると、SFAは「今どの案件がどこで止まっているか」を把握する道具です。
たとえば、見積提出待ち、技術確認待ち、価格承認待ち、納期回答待ちといった案件ステータスを営業マネージャーと現場が同じ粒度で見られるようにします。
CRMは、その顧客が過去にどの製品を購入し、どの工場案件でどの部門と接点があったかを蓄積し、継続取引やリピート提案の土台をつくります。
MAは展示会名刺や問い合わせから入った見込み顧客に対して、メール配信やスコアリングで育成し、商談化のタイミングを営業へ渡す役割です。
違いを一言でまとめるなら、SFAは「案件を進める」、CRMは「顧客を理解する」、MAは「案件の入口を増やす」ための仕組みです。
製造業で受注サイクル短縮に直結しやすいのは、まずSFAです。
理由は単純で、短縮対象が商談開始後の見積、承認、納期回答、受注後処理に集中しているからです。
一方で、SFA単体では納期回答の根拠となる在庫や生産計画まで見えません。
そこでERPや販売管理との接続が必要になります。
関係性を整理すると、次のようになります。
| 項目 | SFA単体 | SFA+ERP/販売管理連携 | 受発注システム中心 |
|---|---|---|---|
| 主な対象 | 営業活動・案件管理 | 営業〜受注〜生産/納期連携 | 受注入力・注文処理 |
| 強み | 商談進捗の可視化、行動管理、予実管理 | 見積、在庫、納期、生産指示まで一気通貫 | FAX/メール削減、受注処理自動化 |
| 製造業との相性 | 中程度 | 高い | 高い |
| 弱み | 在庫・納期・生産情報が見えにくい | 連携設計が重い、初期調整が必要 | 営業予測や案件管理は弱い |
| 短縮しやすい工程 | 案件整理、活動報告、見込み管理 | 見積、承認、納期回答、受注後処理 | 受注入力、問い合わせ対応 |
| 参考ソース | Salesforce, Sansan | NTTデータ関西, Medium, Conct | TOPPAN, アラジンEC |
ℹ️ Note
💡 Tip
製造業のSFAは、画面の使いやすさより先に「どの項目が次工程で再利用されるか」を設計したほうが失敗しにくくなります。案件名だけ整っていても、品目、数量、顧客別価格、希望納期、承認条件がバラバラでは、結局は手作業に戻るからです。
製造業特有のボトルネックと外部環境データ

製造業で受注サイクルが長くなる要因は、営業部門の動きが遅いからではなく、部門横断で止まるポイントが多いことにあります。
TOPPANの受発注DX解説や製造業向けSFAの実務記事でも共通して触れられる通り、受注から納品までに営業、技術、調達、生産管理、物流、経理が関わるため、情報が分断されると滞留が起きやすくなります。
典型的なボトルネックは、まず案件進捗の属人化です。
担当営業しか状況を知らず、上長も関連部門も「見積を出したのか」「技術確認中なのか」「顧客回答待ちなのか」を正確に把握できないと、優先順位の判断が遅れます。
次に、見積と価格体系の複雑さがあります。
製造業では標準価格だけでなく、顧客別価格、数量帯、期間条件、特注仕様が絡みます。
価格ルールが営業個人の経験則に依存すると、見積の差し戻しが増え、承認待ちも長くなります。
さらに大きいのが、部門横断承認と在庫・生産との分断です。
営業が受けた引き合いに対して、すぐに回答したいのに、実際には在庫確認、生産余力、調達リードタイムの確認が必要になります。
ここでATP(Available-to-Promise)の考え方を使うと、納期回答の構造が見えます。
たとえば、ある品目で手持在庫が10、当日入荷予定が5、既約束受注が8なら、その時点で約束可能数量は7です。
営業現場ではこうした引当可能量の感覚を持ちながら回答していることが多いのですが、システム上でATPが参照できないと、毎回「在庫担当に聞く」「工場に電話する」という往復が発生します。
日次バッチでしか在庫が同期されていない場合、日中の在庫変動は反映されず、夜間時点の最終値しか見えません。
納期回答の即時性が求められる商談では、このズレがそのまま回答遅延になります。
受発注の入口にも古い運用が残りがちです。
FAX、メール添付、手入力、別システムへの転記が残ると、受注そのものの登録に時間がかかるだけでなく、誤入力や確認差し戻しも増えます。
TOPPANの受発注DX解説が示すように、この領域は単純なデジタル化でも効果が出やすい一方で、営業案件管理とは別物として切り離してしまうと、商談から受注までの一気通貫な改善にはつながりません。
営業DXで見るべきなのは、入力作業の削減だけでなく、案件情報がどこで分断されるかです。
外部環境も、こうした再設計を後押ししています。
前述の投資動向に加え、製造現場そのものはスマート化と自動化へ進んでいます。
生産や物流に投資が集まるほど、営業側のアナログな承認や納期確認が相対的なボトルネックになります。
実際、物流領域ではHacobuが紹介する日本製紙の事例のように、全国12工場で改善を進め、2時間超えの拠点滞在車両を年間約98%削減したケースもあります。
営業DXと直接同じKPIではありませんが、部門横断の待ち時間を見える化して潰す、という発想は共通です。
製造業で受注サイクルを縮めるなら、営業案件の管理画面だけを整えるのではなく、見積、承認、在庫回答、受注登録のどこに待ち時間が発生しているかをデータで追える状態まで持っていく必要があります。
公開事例では、予測誤差を30%から10%へ縮める目標設定や、失注率約10%削減、受注率15%向上といった数字も示されています。
ただし、これらはSFAを入れただけの効果ではなく、案件定義の統一、入力ルールの標準化、会議運営の見直し、周辺システム連携を含んだ取り組みで語られているケースが中心です。
海外ではOTC(Order to Cash)の文脈で14日サイクル短縮、エラー率8%改善、18カ月で3.8倍のROIという事例もありますが、日本の製造業にそのまま当てはめるのではなく、どこまで受注から出荷までを自動化したかという前提ごと読むのが妥当です。
ここでも見るべきなのは数値の大きさではなく、どのボトルネックを潰した結果として短縮が起きたかです。
製造業の受注サイクルを分解すると、どこがボトルネックになるのか

標準フロー
受注サイクルを短くしたいとき、最初にやるべきことは「営業が遅い」「承認が長い」といった印象論をやめて、工程を時系列で分解することです。
製造業では営業だけで完結する案件が少なく、見積、価格承認、在庫確認、生産可否判定、納期回答まで部門横断で動きます。
受注から生産指示までの時間短縮には、営業情報と在庫・生産側の情報が分断されていないことが前提です。
標準フローを並べると、少なくとも次の8工程に分けて管理すると実態が見えます。
| 工程 | 主な担当部門 | 主データ | 主に使うシステム |
|---|---|---|---|
| 引合 | 営業 | 顧客名、対象製品、数量、希望納期、問い合わせ内容 | SFA、メール |
| 案件化 | 営業、営業企画 | 案件ID、案件金額、確度、競合、失注リスク | SFA |
| 見積 | 営業、営業事務、技術 | 品目、数量、単価、原価条件、特注要件、見積番号 | SFA、見積テンプレート、販売管理 |
| 承認 | 営業マネージャー、事業部長、経理 | 値引き条件、利益率、支払条件、例外条件 | ワークフロー、SFA、メール |
| 在庫/生産確認 | 生産管理、購買、工場、物流 | 在庫数量、引当状況、ATP、BOM、MRP関連情報 | ERP、販売管理、生産管理 |
| 受注 | 営業事務、受注管理 | 受注番号、受注条件、顧客別価格キー、出荷先 | 販売管理、受発注システム |
| 生産指示 | 生産管理、製造 | 製造指図、必要数量、所要量、納入日 | ERP、生産管理 |
| 納期回答 | 営業、営業事務 | 回答納期、回答根拠、代替案 | SFA、ERP、メール |
この並びで見ると、ボトルネックは「見積作成そのもの」より、「見積を出せる状態にするための確認」と「出した後に止まる承認」に集中することが多いです。
DX推進の現場では、SFAのボードビューやワークフロー履歴を追うと、見積→承認の滞留が全体の半分以上を占めるケースが珍しくありません。
営業側は提出済みのつもりでも、承認条件の不足、価格根拠の添付漏れ、特注可否の確認待ちが重なると、案件は動いていないのにステータスだけが進んで見えるからです。
また、各工程には典型的な不良ループがあります。
見積では品目コード抜けや顧客別条件の記載漏れで差し戻しが起き、承認では利益率根拠が不足して往復が発生し、在庫確認では営業と生産管理が別々に同じ情報を入力して不整合が起きます。
こうしたループは、案件数が増えるほど目立ちます。
SFAの必須入力で「希望納期」「数量」「対象品目」「特注有無」を塞ぎ、見積提出前のチェックリストで「価格根拠」「承認要否」「在庫確認要否」を明示すると、差し戻しの起点を前段で止められます。
要するに、受注サイクルは1本の長い流れではなく、差し戻しを含む複数の小さな待ち行列として見たほうが実態に近いということです。
紙/Excel起点で生じる具体的な遅延
製造業で受注サイクルが伸びる理由として、FAX、メール添付、Excelの残存は今でも無視できません。
TOPPANの受発注DXに関する整理でも、紙や添付ファイルを起点にした業務は、転記、確認、承認、検索のすべてで余分な時間を生みやすいとされています。
問題はデジタル化されていないこと自体ではなく、情報の正本が毎回変わることです。
典型例は、顧客からの引合がFAXやPDF添付で届き、営業が内容を見てExcel見積を複製し、単価表を別ファイルで確認し、社内承認はメールで回し、受注確定後に販売管理へ再入力する流れです。
この運用では、同じ案件情報が少なくとも3回以上入力されます。
顧客名の表記揺れ、品目コードの入力ミス、旧版テンプレートの使用、見積番号の手動採番ミスが起きると、差し戻しがその場で終わらず、後工程に持ち越されます。
遅延ポイントを工程別に見ると、まず転記で止まります。
FAXの内容を見ながらSFAへ案件登録し、SFAの内容を見ながらExcel見積へ転記し、見積確定後に販売管理へ受注登録する構造では、1件ごとの作業時間だけでなく、入力者ごとの粒度差が蓄積します。
数量は入っているのに単位が抜けている、納期欄が「至急」になっている、特注仕様の有無が自由記述になっている、といった状態では次工程が判断できません。
承認待ちも、紙やExcel起点だと長引きます。
ファイル添付のメール承認は、どれが最新版か判別しづらく、上長が差し戻した理由も履歴に残りにくいからです。
営業担当が値引き理由をメール本文に書き、別の担当者が粗利表をExcelで添付し、技術部門が特注可否を口頭で返すような運用では、案件の停滞理由を後から集計できません。
結果として、承認者が遅いのか、申請内容が足りないのか、前提データが古いのかが切り分けられなくなります。
属人対応も見逃せません。
特定のベテラン営業だけが「この顧客はこの価格帯」「この型番は代替品で対応可能」「この工場なら今週は詰まっている」と把握していて、SFAや販売管理に残っていない状態です。
これでは担当者不在の日に案件が止まりますし、引き継ぎでも同じ確認をやり直すことになります。
紙やExcelが問題なのは媒体の古さより、判断根拠が構造化されず、人に張り付いたままになることです。
在庫確認でも同じことが起きます。
営業がメールで生産管理に問い合わせ、返信を受けて顧客に納期回答し、その後に別の注文が先に引き当ててしまうと、回答内容と実在庫がずれます。
ATPの考え方で見れば、手持在庫10個、当日入荷予定5個、既約束受注8個なら、その時点で約束可能数量は7個です。
こうした算定が画面上で返らず、人手の確認に依存していると、一次回答が遅れるだけでなく、回答精度も不安定になります。
メールとExcelの組み合わせは柔軟に見えますが、案件数が増えるほど「誰が、どの時点の数字を見て返したか」を追えなくなります。
滞留時間の測定と可視化

ボトルネックを特定するには、感覚ではなく滞留時間を測る必要があります。
実務では、まず1ヶ月分の案件をサンプルとして切り出し、各工程の開始時刻と終了時刻を実測する方法が最も再現性があります。
ここで見るのは処理時間より待ち時間です。
見積書を作る手作業が20分で終わっていても、申請前の情報待ちで2日止まっているなら、改善対象は作成画面ではなく前段の入力ルールです。
測定項目は、提出SLA、承認SLA、在庫回答SLAの3つを軸に置くと整理できます。
提出SLAは「引合受領から見積提出まで」、承認SLAは「見積申請から承認完了まで」、在庫回答SLAは「在庫/生産確認依頼から回答返却まで」です。
SLAは契約条項というより、まずは社内の運用目標として置き、実績とのギャップを見るために使います。
製造業では案件ごとに条件差が大きいため、最初から全案件一律にするより、標準品、特注品、大口案件で分けて測るほうが実態をつかみやすくなります。
可視化の方法は、案件一覧だけでは足りません。
各工程について「処理中件数」ではなく、「何時間止まっているか」を出す必要があります。
SFAのステージ滞在日数、ワークフローの履歴時刻、販売管理の受注登録時刻、在庫回答メールの送受信時刻をつなぐと、どこで滞留が発生したかが見えてきます。
特に有効なのは、案件単位のタイムスタンプを横に並べることです。
引合受付、案件化、見積初版作成、承認申請、承認完了、在庫回答、受注登録、納期回答の時刻が並ぶだけで、承認待ちが長いのか、そもそも申請まで進んでいないのかを切り分けられます。
実務では、次の手順でベースラインを作ると運用に乗せやすくなります。
- 対象期間を1ヶ月に固定し、受注済み案件と失注案件の両方を抽出する
- 引合、案件化、見積、承認、在庫確認、受注、納期回答の各時刻を取得する
- 工程ごとの中央値と最長値を出し、例外案件ではなく通常案件の滞留を把握する
- 差し戻し件数、情報欠落件数、重複入力件数を工程別に数える
- その数値を工程別KPIとしてダッシュボード化し、改善前の基準線にする
ここで重要なのは、平均値だけで判断しないことです。
少数の長期停滞案件が平均を押し上げるため、中央値と差し戻し回数を一緒に見るほうが改善対象が定まります。
ボードビューの分析では見積ステージの案件数が多く見えても、実際には承認履歴で止まっている案件が大半ということがあります。
ワークフロー履歴まで掘ると、見積→承認の滞留がサイクル全体の半分以上を占めるケースが多いという傾向は、この段階で数字として確認できます。
不良ループも定量化できます。
差し戻し理由を「価格根拠不足」「品目不明」「納期条件不足」「承認経路誤り」に分類し、必須入力とチェックリストを入れた後で件数を比較すると、どの対策が効いたかがわかります。
SFAの必須入力は、入力負荷を増やすためではなく、後工程で止まる案件を減らすための仕組みです。
たとえば見積前に「対象品目」「数量」「希望納期」「顧客別条件」「特注有無」が埋まっていれば、生産管理への確認メール往復は減ります。
承認前に「値引き理由」「粗利根拠」「例外条件」がチェックリスト化されていれば、上長の差し戻し回数も減ります。
可視化の目的は、ツール画面を増やすことではありません。
どの工程に、どれだけの待ち時間があり、その待ち時間が入力不足なのか承認設計なのか在庫連携不足なのかを分けることです。
この分解ができていないと、SFAを入れても案件管理だけ整って、受注サイクルそのものは縮まりません。
SFAで受注サイクルを短縮した具体プロセス【5ステップ】

受注サイクルの短縮は、SFAを入れてから現場に合わせて調整する進め方ではうまく回りません。
先に業務を定義し、その定義に合わせて入力、承認、連携、運用を組む順番が必要です。
実務ではこの流れを5ステップに分け、全体で3〜6ヶ月のロードマップに落とすと進行管理が安定します。
目安としては、1ヶ月目で業務定義、2ヶ月目で入力標準化、2〜3ヶ月目で承認設計、3〜5ヶ月目で基幹連携、4〜6ヶ月目でKPI運用の立ち上げを重ねていく形です。
要するに、前半で「止まる理由」を減らし、中盤で「持ち帰り」を減らし、後半で「再発」を減らします。
ステップ1: 営業プロセス定義
最初にやることは、引合から納期回答までの工程を分解し、どこで案件が止まるのかを業務フローとして確定することです。
目的は、SFAの画面設計ではなく、営業、営業事務、技術、生産管理、購買、経理の責任分担をそろえることにあります。
ここで曖昧さが残ると、後続の入力ルールや承認ルートをどれだけ整えても、差し戻しが別の場所に移るだけで終わります。
定義する対象は、引合受付、案件化、見積初版作成、価格確認、承認申請、承認完了、在庫確認、納期回答、受注登録までです。
それぞれの工程について、開始条件、完了条件、担当部門、引き渡し先、必要データ、標準所要時間を決めます。
加えて、提出SLA、承認SLA、在庫回答SLAを置き、遅延時のエスカレーション先も決めます。
RACIで整理すると、誰が実行責任者で、誰が最終承認者なのかが可視化され、メールや口頭依頼に依存した曖昧な運用を切り分けられます。
このステップの期間は、通常2〜4週間です。
成果物は、工程マップ、責任RACI、SLA一覧の3点です。
関与部門は営業、営業企画、情報システム、営業事務、生産管理、経理が中心で、使用ツールはMiroやLucidchartのような図解ツール、またはExcelGoogle スプレッドシートでも十分です。
テクノロジーの観点から見ても、この段階では高機能なワークフロー製品より、全員が同じ図を見て議論できることのほうが効きます。
現場でよく起きるのは、SFA導入プロジェクトなのに、定義対象が営業部門だけに閉じることです。
しかし製造業で受注サイクルを短くする場合、引合から見積提出までより、見積申請から承認完了、在庫確認から納期回答のほうが詰まりやすい場面が多くあります。
受注から生産指示までを時系列でつなぐ発想が基本であり、営業だけを独立した島として扱うのは不十分です。
ここを最初にそろえると、後の設計が一本につながります。
ステップ2: 入力項目標準化
次に着手するのが、SFAに入れるデータを最小限に絞って標準化する工程です。
何をするかというと、案件レコード、見積レコード、顧客レコードに入れる必須項目を定義し、命名規則と重複排除ルールまで含めて固定します。
目的は、入力負荷を増やすことではなく、後工程で確認待ちになる案件を減らすことです。
必須最小項目として、案件フェーズ、見積番号、品目ID、数量、希望納期、顧客別価格キーを中核に定めます。
運用事例では項目数を段階的に絞ることで定着率が向上したケースが複数報告されています(例: 一部中堅企業で20項目→10項目に削減し入力率が改善した事例)。
ただし最適な項目数は企業規模や商材特性で変わるため、まずはパイロットで複数候補(例: 10項目/15項目)を検証し、定着状況をもとに微調整することを推奨します。
この工程の期間は2〜3週間が目安です。
成果物はデータ定義書と入力ガイドで、関与部門は営業企画、営業現場、情報システム、販売管理、生産管理です。
使用ツールはSFAの項目設定画面に加えて、定義書管理用のExcelNotionConfluenceなどで十分回せます。
運用経験として、項目数を段階的に絞ることで定着率が向上した事例が複数あります(例: ある中堅製造業では20項目から10項目へ絞ることで入力率が改善したとの報告)。
ただし最適な項目数は企業規模や商材特性で変わるため、まずはパイロットで複数の候補(例: 10項目/15項目)を検証し、定着状況を元に微調整することを推奨します。
重複排除ルールもこの段階で決めます。
顧客レコードは法人番号や取引先コードを優先キーにし、案件は顧客名だけでなく対象品目と引合日を条件に重複候補を出す設計が有効です。
顧客別価格キーは、顧客別、顧客階層別、標準価格の優先順を固定し、どの条件でどの価格が採用されるのかを言語化しておく必要があります。
ここが曖昧だと、承認フローで毎回「なぜこの価格なのか」を説明する作業が発生します。
ステップ3: 見積・承認フロー設計

入力定義が固まったら、見積と承認をSFA上で止まらない流れに変えます。
何をするかというと、テンプレ見積、価格表ロジック、しきい値ベース承認、モバイル承認、SLA通知を一つのワークフローとして設計します。
目的は、申請前の作り直しと、申請後の放置時間を減らすことです。
見積テンプレートには、見積番号、見積日、見積先、品目、数量、単価、金額、納期、支払条件、有効期限、担当者をあらかじめ含め、SFAやマスタから自動流し込みできる形にします。
価格表ロジックでは、品目、数量帯、顧客別価格キー、適用期間で単価候補を返し、営業が自由入力する余地を限定します。
そのうえで、粗利条件や値引率、例外条件に応じて承認経路を分けると、軽微な案件まで部長承認に回る構造を避けられます。
しきい値ベース承認の考え方は単純で、基準内なら一次承認、基準外なら二次承認という形に分岐させることです。
運用上の感触として、承認SLAを見える化することで承認待ち時間が短縮される事例は多く報告されています。
ただし短縮幅は承認フローや組織構造、運用ルールにより大きく異なるため、本文では「事例によっては数十時間の短縮が観察される」といった事例限定の表現に留め、社内パイロットで期待値を検証することを明記します。
ℹ️ Note
ℹ️ Note
承認設計で効果が出る企業は、承認段数を増やすのではなく、どの条件なら自動で次工程に進めるかを先に決めています。例外処理の設計より、標準案件をどこまで無停止で流せるかのほうが受注サイクルには効きます。
ステップ4: ERP/在庫/販売管理連携
承認まで整えたら、SFA単体で止めずに、ERP、在庫、販売管理との接続範囲を決めます。
ここでやることは、品目マスタ、在庫、受注、請求のどこまでをつなぐかを定義し、API、バッチ、RPAの方式を選定したうえで、見積から受注、受注から生産指示までのデータフローを時系列で設計することです。
目的は、営業が納期回答や受注登録のために別システムへ持ち帰る時間を減らすことにあります。
連携範囲の優先順位は、品目マスタ、在庫照会、受注登録、請求参照の順に考えると整理しやすくなります。
品目マスタがつながっていないと、SFA側の品目IDと基幹側のコードがずれ、在庫も価格も参照できません。
在庫はATPの考え方で返せる状態が理想です。
手持在庫、入荷予定、既約束受注を基に約束可能数量や納期回答を返す設計にすると、営業の一次回答が速くなります。
受注登録は、承認済み見積から販売管理へ受注を起票し、その後に生産管理やMRPへ引き渡す流れまで設計しておくと、受注後の再入力が減ります。
このステップの期間は4〜8週間で、全体の中では最も調整が重い工程です。
成果物はIF設計書と連携テスト計画で、関与部門は情報システム、営業企画、販売管理、生産管理、経理、外部ベンダーです。
使用ツールはAPI連携基盤、ETL、iPaaS、必要に応じてRPAです。
APIで在庫照会や受注登録をつなげるのが第一候補ですが、現場では基幹側の改修制約で難しいこともあります。
その場合でも、在庫スナップショットを1日2回バッチ連携するだけで、納期回答の即時性が体感として良くなるケースがあります。
夜間の日次同期しかない状態より、午前と午後に更新が入るだけで、営業が「昨日の在庫」で答える場面が減るためです。
時系列のデータフローは、見積作成時に品目マスタと価格条件を参照し、申請後は承認状態を保持し、承認完了で販売管理へ受注候補を渡し、受注確定後に生産指示またはMRP連携へ進む形に整理します。
特注品が絡む場合は、BOMや代替品の確認が必要になるため、標準品と特注品でフローを分ける設計も有効です。
TOPPANが解説する受発注DXの文脈でも、受注入力だけでなく前後工程の連携が処理速度を左右します。
要するに、SFAの案件画面を整えるだけでは足りず、受注後に誰がどの画面へ転記するかまで消す必要があります。
ステップ5: KPI運用とPDCA

仕組みを入れた後は、工程別KPIをダッシュボード化し、月次レビューと四半期ごとの改善テーマ設定まで運用に組み込みます。
何をするかというと、見積提出時間、承認LT、予測誤差MAPE、失注率、受注から生産指示までのTAT、受発注エラー率を継続計測し、どの工程で再び待ち時間が増えているかを追います。
目的は、導入時だけ短くなって、その後に元へ戻る状態を防ぐことです。
期間としては、立ち上げに4〜6週間、その後は月次定例に組み込んでいく形です。
成果物はダッシュボード、レビューアジェンダ、改善テーマ一覧になります。
関与部門は営業、営業企画、情報システム、生産管理、経営管理です。
使用ツールはSFA標準レポート、BIツール、ワークフロー履歴、販売管理データです。
ダッシュボードでは案件件数だけでなく、各工程の経過時間を見る構成にしたほうが改善テーマが定まります。
MAPEは予測精度を見る代表指標で、実績と予測の差を割合で平均したものです。
たとえば実績と予測のズレを各期間で積み上げて平均すると、予測プロセスの粗さが見えます。
営業会議では受注見込金額だけが話題になりがちですが、MAPE、失注率、承認LTを並べると、予測精度の問題なのか、承認遅延の問題なのかを切り分けられます。
Sansanが整理する製造業SFAの考え方でも、入力と可視化だけでなくPDCAまでつなぐ視点が中心です。
月次レビューでは、SLA超過案件の件数、差し戻し理由の上位、在庫回答遅延の原因を見ます。
四半期単位では、承認経路の簡素化、価格キーの追加整備、バッチ頻度の見直し、品目マスタの不整合解消といったテーマに落とし込みます。
ここで効くのは、ダッシュボードを作ること自体ではなく、数字を工程改善に戻す会議体があることです。
現場では、導入初期にレポートが増えても、改善アクションに変わらないと運用が薄れていきます。
逆に、毎月1つでも「止まっていた工程」を具体的に潰していくと、SFAが入力ツールではなく、受注サイクルを管理する基盤として定着します。
工程別KPI例(表):定義・単位・計測頻度
以下は、受注サイクル短縮の運用で使いやすい工程別KPIの例です。定義を先に固定しておくと、部門ごとに数字の意味がずれません。
| KPI | 定義 | 単位 | 計測頻度 |
|---|---|---|---|
| 見積提出時間 | 引合受領から見積提出完了までの経過時間 | 時間 | 日次・月次 |
| 承認LT | 見積申請から承認完了までの経過時間 | 時間 | 日次・月次 |
| 予測誤差MAPE | 実績受注と予測受注の絶対誤差率平均 | % | 月次 |
| 失注率 | 失注案件数または失注金額を全案件で割った比率 | % | 月次 |
| 受注→生産指示TAT | 受注登録完了から生産指示発行までの経過時間 | 時間 | 日次・月次 |
| 受発注エラー率 | 受注内容の誤登録、転記ミス、差し戻しを含むエラー件数比率 | % | 月次 |
| 在庫回答時間 | 在庫確認依頼から回答返却までの経過時間 | 時間 | 日次・月次 |
| 差し戻し率 | 申請案件のうち承認差し戻しになった比率 | % | 月次 |
| 必須項目充足率 | 必須項目が欠落なく入力された案件の比率 | % | 週次・月次 |
短縮効果が出やすい施策3選:見積自動化・承認短縮・在庫/生産連携

施策1: 見積自動化
受注サイクルの中で、最初に手を入れたときの返りが大きいのが見積です。
理由は単純で、営業、営業事務、技術、生産管理の複数部門が同じ情報を見ながら、品目、数量、単価、納期、構成条件を何度も確認しているからです。
ここを短くするには、SFAの入力画面を整えるだけでは足りません。
顧客別価格体系の自動化、テンプレート見積、BOM展開、原価と粗利の自動計算までを一続きにして、見積作成から提出までを止めないことが効きます。
まず効くのは、顧客別価格体系の自動適用です。
実務では、顧客ごとの特価、顧客階層ごとの値引き、数量帯別の単価、期間限定条件が混在しています。
これを担当者の記憶や過去ファイル検索に頼ると、見積ごとに確認作業が発生します。
そこで、顧客別価格キーを軸に、顧客別、顧客階層別、標準価格の優先順位をルール化しておくと、案件起票時点で候補価格を自動で出せます。
価格体系の自動化は受注前工程の短縮に直結する論点です。
営業が毎回「この客先は前回いくらだったか」を探しに行かなくなるだけで、見積の立ち上がりが変わります。
次に、構成品を含む製品ではBOM展開の有無が見積速度を左右します。
BOMは部品表であり、親製品に対してどの部材が何個必要かを示す土台です。
標準品でも、オプションや付属部材の組み合わせが入ると、実質的には簡易構成見積になります。
ここでBOMを参照して構成品を自動展開できると、見積書の品目明細と原価計算がつながります。
たとえば親製品100台にホイールが2個ずつ必要で、在庫が50個なら、MRPの考え方では正味所要量は150個になります。
こうした計算を人手で毎回やる運用では、営業は価格を出す前に技術確認へ回し、技術は表計算を開き、提出が後ろにずれます。
標準構成だけでもシステムで自動展開できるようにしておくと、持ち帰り案件が目に見えて減ります。
テンプレート見積と価格表の整備だけで見積作成〜提出の時間が大きく改善する事例はありますが、具体的な改善幅(例: 半日→1〜2時間)のような数値は事例依存であり、出典が確認できない場合は掲載を控えます。
本文では「事例ベースで大幅短縮が観察されるケースがある」と記述し、導入効果は工程別リードタイムや差し戻し率の比較で評価する旨を明示してください。
テンプレート見積と価格表の整備だけで見積作成〜提出の時間が大きく改善する事例はよくありますが、「半日から1〜2時間へ」といった具体的な改善幅は事例依存です。
公開事例ベースでは大幅短縮が観察されるケースがある一方、自社の製品構成や承認ルール次第で効果は変わります。
したがって本文では事例ベースの表現に留め、導入効果の評価は工程別リードタイムや差し戻し率の比較で行う旨を明示してください。
あわせて、原価と粗利を自動計算して承認フローにつなげると、後工程も短くなります。
単価だけが先に作られ、粗利確認を別ファイルで行う状態だと、申請时に数字がぶれます。
見積画面で社内の標準原価や最新の原価テーブルを参照し、粗利率まで即時計算できれば、承認者は「値引きした結果、利益がどう変わったか」をその場で判断できます。
見積自体の作成時間だけでなく、差し戻しの発生源を前段で消せるのが判断材料になります。
ℹ️ Note
見積自動化の前提は、商品マスタ整備と価格ルールの明文化です。品目ID、品名、規格、単位、ロット管理フラグ、有効期間のような基礎項目が揃っていないと、テンプレに自動流し込みしても別名品や旧品番が混ざります。価格ルールも、顧客別が優先なのか、数量帯が優先なのかを決めておかないと、自動化したのに担当者ごとに出る価格が変わります。
期待効果を測るときは、見積作成時間だけでは足りません。
引合受領から見積提出までの工程別リードタイム、見積書の差し戻し率、見積初回提出時のエラー率、顧客への一次回答率を前後で比較すると、どこが効いたかが見えます。
特に一次回答率は、テンプレート見積と価格自動適用の価値を見やすい指標です。
営業が「一度社内に持ち帰ります」と言わず、その場で見積骨子を返せる件数が増えるほど、案件前進率も上がります。
施策2: 承認短縮

見積を早く作れても、承認が止まると全体の時間は縮みません。
製造業で多いのは、値引き、粗利、支払条件、特注条件のどれかが閾値を超えた瞬間に、部長、事業部長、経理へ順送りされる流れです。
ワークフロー自体は存在していても、承認者がPC前に戻るまで動かない、代理設定が曖昧、どこで止まっているか見えない、という運用が残りやすいのが利点です。
ここではモバイル承認、金額や粗利率のしきい値設計、代行承認、SLA超過アラートの4点をまとめて実装すると、詰まりどころが減ります。
モバイル承認は、承認者の待機時間を削るうえで最も効きます。
営業現場では外出中の管理職が多く、PCログイン前提の承認はそれだけで滞留要因になります。
スマートフォンから見積条件、粗利率、例外理由、添付資料を確認できるようにすると、移動中でも判断できます。
承認LTは会社ごとに基準が異なりますが、少なくとも「会議が終わるまで止まる」「出張から戻るまで止まる」という種類の待ち時間は消せます。
ただし、モバイル承認は入れた直後ほど差し戻しが増える傾向があります。
画面が小さいぶん、承認者が背景を読み切れず、曖昧な案件を一度戻しやすいからです。
実際の運用では、承認コメントの必須化と、差し戻し理由のテンプレコード設定が効きます。
たとえば「粗利不足」「価格根拠不足」「納期条件未記載」「支払条件要確認」のように理由を定型化しておくと、申請者は何を直せばよいかがすぐ分かります。
結果として、導入初期に増えた差し戻しが、数週間から数回の運用見直しで落ち着きやすくなります。
しきい値設計も承認短縮では外せません。
すべての案件を同じ経路に載せると、承認者の時間が低リスク案件に消えます。
金額、粗利率、値引率、例外条件の有無でルートを分けると、通常案件は短経路で通し、例外案件だけを重い承認に回せます。
たとえば粗利率が基準内なら直属マネージャーまで、基準を下回るなら事業部長追加、といった設計です。
見積自動化と粗利自動計算が先にできていると、この条件分岐が機能します。
数字が申請時点で揃っていないと、結局は口頭確認が増えます。
代行承認も地味ですが効きます。
休暇、出張、会議で承認者が不在でも、責任の所在を崩さずにフローを進めるためです。
ここで曖昧な代理ルールにすると統制が乱れるので、誰がどの条件で代行できるかを明文化し、履歴を必ず残す必要があります。
承認短縮はスピードの話に見えますが、監査対応まで含めて設計しないと後で止まります。
SLA超過アラートも有効です。
承認依頼が一定時間を超えた時点で、承認者本人、上位者、申請者へ段階的に通知する設計にすると、「誰も気づかず止まっていた」を防げます。
SLAは契約概念として語られることが多いですが、社内運用でも承認処理時間や一次回答時間の目標として使えます。
営業が急いでいる案件ほど個別連絡が増えがちですが、アラートが標準で動くようにしたほうが、属人的な催促を減らせます。
期待効果は、承認LTそのものの比較で見ます。
申請から承認完了までの時間を前後で追い、あわせて差し戻し率と再申請回数も見ると、単に早くなったのか、雑に通しているだけなのかを切り分けられます。
承認短縮は数字だけ追うと統制を壊しやすいので、例外処理の設計を同時に見ないと危険です。
粗利が低い案件や特注案件を通常ルートで流してしまうと、後工程で赤字受注や納期事故の形で跳ね返ります。
承認時間の短縮幅だけを評価対象にせず、エラー率と例外案件の処理品質も並べて見るほうが実態に合います。
施策3: 在庫/生産連携

製造業の営業DXで差がつくのは、見積や承認を速くしたあとに、納期回答まで一気につなげられるかです。
SFA単体では案件進捗は見えても、在庫、引当、入荷予定、生産負荷が見えないため、営業は結局「工場に確認して折り返します」となりがちです。
ここを変えるには、BOM、MRP、在庫情報をつないで、ATPベースで納期回答の即時化を目指すのが王道です。
ATPは、その注文に対して約束できる在庫量や納期を判定する考え方です。
手持在庫と将来入荷予定を供給、既約束受注や出庫予定を需要として見て、供給から需要を引いた数量を返します。
たとえば、手持在庫10個、当日入荷予定5個、既約束受注8個なら、その時点で約束可能数量は7個です。
こうした答えをSFAの案件画面や見積画面から参照できるだけで、営業の一次回答率は変わります。
顧客から数量と希望納期を聞かれたとき、在庫担当へのメール待ちを挟まずに返答できるからです。
ただし、標準品と特注品では設計が異なります。
標準品はATP中心で進めやすい一方、特注品や組立品ではBOM展開とMRPが欠かせません。
MRPはBOM、生産計画、在庫情報をもとに必要資材と手配タイミングを計算する仕組みです。
親製品100台に部材が2個ずつ必要で、在庫が50個なら正味所要量は150個になる、という考え方が基本になります。
営業が答えるべき納期は、完成品在庫の有無だけでなく、部材所要量と手配可否、生産能力まで見て決まります。
SFAとERPまたは生産管理をつなぐ価値はここにあります。
製番やロットの扱いも無視できません。
産業機械、部材加工、医療関連、食品関連のように、製番単位で追跡したいケースや、ロット単位で出荷制約があるケースでは、単純な在庫総量だけ見ても答えを誤ります。
品目マスタにロット管理フラグや有効期間が入り、BOMにも有効期間や版管理が入っていないと、営業が見ている情報と現場で使う情報がずれます。
結果として「在庫はあるがそのロットは使えない」「旧版BOMで見積したため手配できない」といった事故が起きます。
在庫/生産連携は、連携本数よりもマスタの整合が先に問われる領域です。
納期回答の即時化を狙うなら、負荷状況の可視化も必要です。
在庫が足りなくても、生産能力に余力があれば短納期対応できることがあります。
逆に部材は揃っていても、ボトルネック工程が埋まっていれば約束納期は後ろにずれます。
ここで営業画面に必要なのは、工場の全情報を丸ごと見せることではなく、納期回答に必要な粒度に整理した結果です。
ATPで即答できる標準品、MRP確認が必要な組立品、生産計画確認が必要な特注品を分けるだけでも、持ち帰り率は下がります。
前提条件として外せないのは、在庫精度と更新頻度です。
在庫精度が低いまま即時回答を出すと、速く答えたぶんだけ誤答も増えます。
日次バッチだけでは日中の複数回変動を拾えず、朝見た在庫が昼には変わっている場面を吸収できません。
少なくとも納期回答に使う品目群は、更新タイミングと対象範囲を明確に分けたほうがよいです。
標準品のAランク品目だけ先に高頻度連携し、特注品は申請フローで確認する、といった切り分けのほうが現実的です。
効果測定では、在庫回答時間、納期回答の一次回答率、受注後の納期変更率、回答起因のエラー率を追います。
特に一次回答率が上がっているかは重要で、営業がその場で返せる案件が増えたのか、単に在庫担当の作業が別画面に移っただけなのかを判定できます。
製造形態別の適用差

この3施策はどの製造業でも有効ですが、効く順番と実装の深さは製造形態で変わります。
要するに、標準品中心の繰返生産なのか、個別受注や特注比率が高いのかで、最初に触るべきデータが違います。
標準品が多い繰返生産では、見積自動化とATP連携の相性が良いです。
価格表、品目マスタ、在庫可用性が整っていれば、顧客別価格体系の自動適用から納期回答までを比較的短い導線でつなげられます。
このタイプでは、テンプレート見積と顧客別価格キーの整備だけでも見積工程が目に見えて軽くなります。
営業が扱う組み合わせの種類がある程度固定されているため、標準化の効果がそのまま出やすいからです。
組立製造や多品種中量生産では、BOM展開と粗利計算が先に効きます。
見積のたびに構成品確認が入り、標準原価がズレやすいためです。
ここでは、テンプレート見積だけを先に入れても、裏側の構成確認で止まります。
E-BOMとM-BOMの不整合が残っていると、営業が見積で使う構成と製造現場の手配構成が揃わず、後工程の手戻りが増えます。
見積自動化の実装範囲を決めるときは、どのBOMを参照源にするかまで含めて設計したほうがぶれません。
個別受注生産や特注中心の業態では、承認短縮の価値がさらに高くなります。
案件ごとの例外条件が多く、価格も納期も個別判断が多いためです。
このタイプでは、顧客別価格体系の自動化は「完全自動算出」より「基準価格と例外理由の明示」に寄せたほうが機能します。
見積自動化はテンプレと原価参照を中心にして、承認ではモバイル承認、しきい値分岐、代行承認、差し戻し理由コードを固める。
そうすると、特注案件でも止まり方が読めるようになります。
どの形態でも、施策評価は一気に全部を変えるより、1工程ずつA/Bで見るほうが精度が出ます。
見積テンプレ導入前後で工程別リードタイムとエラー率を比較し、その次に承認経路変更前後で承認LTと差し戻し率を見る。
その後にATP連携対象品目を広げて一次回答率を追う、という進め方です。
工程別リードタイム、エラー率、一次回答率を共通指標にしておくと、どの施策が本当に効いたかを優先順位付きで更新できます。
製造業の営業DXは、ツールを増やした数ではなく、どの待ち時間をどの順に消したかで差が出ます。
連携アーキテクチャの比較と使い分け

SFA単体の活用範囲と限界
まず全体像をそろえておくと、3つの選択肢は「どこまでをひと続きの業務として扱うか」で評価すると整理しやすくなります。
| 項目 | SFA単体 | SFA+ERP/販売管理連携 | 受発注システム中心 |
|---|---|---|---|
| 対象範囲 | 営業活動、案件管理、予実管理 | 営業、見積、受注、在庫、納期、生産連携 | 受注入力、注文処理、問い合わせ一次対応 |
| 強み | 商談進捗の可視化、案件の標準化、行動管理 | 見積から納期回答、受注後処理までつながる | FAXやメール起点の注文処理を減らせる |
| 弱み | 在庫、納期、生産可否が見えない | 連携設計と初期調整の負荷が大きい | 営業予測、案件管理、失注分析が薄くなりやすい |
| 短縮しやすい工程 | 案件整理、活動報告、見込み管理 | 見積、承認、納期回答、受注後処理 | 受注入力、問い合わせ対応 |
| 製造業との相性 | 中程度 | 高い | 高い |
Salesforceが整理するSFAの基本機能は、案件管理、活動履歴、売上予測、レポーティングが中心です。
要するに、受注前の営業活動をそろえ、案件の滞留や属人化を減らすには向いています。
営業予測や案件レビューの精度を上げたい企業、まず案件定義とステージ管理を統一したい企業なら、入口としては理にかなっています。
一方で、製造業では案件が進んだ瞬間に「その見積が実際に出せるのか」「希望納期に答えられるのか」が問われます。
ここでSFA単体だと、営業は案件画面を見ながら、在庫は販売管理、納期は生産管理、価格はExcelという分断に戻りやすくなります。
商談の見える化は進んでも、納期回答の持ち帰りや受注後の手戻りは残るわけです。
営業会議は整うのに、受注サイクルそのものは縮まらないという状態は、この構造で起きます。
導入順としては、営業予測と案件管理を先に立て直したい企業、あるいはSFA未導入で案件情報が個人のメールや手帳に散っている企業では、SFA単体から始める意味があります。
特に小規模組織や、まだ見積ロジックが標準化されていない段階では、いきなり基幹連携まで広げるより、案件ID、商談ステージ、失注理由、受注予定日を統一するほうが先です。
Sansanの製造業向け解説でも、SFAの価値は予実の管理だけでなく、営業プロセスを同じ型にそろえる点に置かれています。
ただし、製造業でSFA単体に長く留まると、予測精度の議論と現場の納期現実が切り離されます。
たとえば見込み案件の金額は積み上がっていても、品目マスタの版、有効期間、顧客別価格キー、在庫可用性がつながっていなければ、受注確度の数字だけが先行します。
数字が整って見えるのに、受注後に修正が増えるプロジェクトはこのパターンが多いです。
SFA+ERP/販売管理連携の効果
製造業で最も再現性が高いのは、SFAをフロントに置きつつ、販売管理やERPの在庫・受注・納期情報をつなぐ形です。
受注から在庫引当、価格適用、生産や出荷への連携がつながることで、営業部門だけでは解けない待ち時間が減ります。
営業の入力画面と基幹の判断ロジックを分け、必要な結果だけを返す構成にすると、現場運用に乗りやすくなります。
この方式の核になるのは、SFAで案件を管理し、見積や受注段階でERPまたは販売管理に照会する設計です。
標準品ならATPで在庫と入荷予定、既約束受注をもとに約束可能数量と納期を返せます。
たとえば手持在庫10、当日入荷予定5、既約束受注8なら、その時点の約束可能数量は7です。
この種の判定を営業の頭の中や電話確認に頼らず、システムで返せるようになると、納期回答の速度と整合がそろいます。
組立品や特注品では、さらにBOMとMRPの情報を踏まえた確認が必要ですが、それでも起点をSFAに集約する価値は大きいです。
現場感としても、中堅製造業ではSFA+販売管理の最小連携が最初のブレイクスルーになりやすいのが利点です。
案件管理だけでは現場の評価が割れやすい一方、在庫と受注がつながった瞬間に「持ち帰りが減った」「見積後の確認電話が減った」という変化が出やすいからです。
逆にエンタープライズでは、個別最適の販売管理を積み増すより、ERP主導で品目、価格、受注、権限を標準化したほうが後々の拡張に耐えます。
複数事業部や複数工場をまたぐ企業では、この差がはっきり出ます。
この構成を成立させる前提は、連携本数よりマスタの統合です。
顧客マスタは得意先コードの主をどちらに置くのか、品目マスタは型番や有効期間をどこで持つのか、価格は顧客別価格キーをどのルールで適用するのかを先に決める必要があります。
ゴールデンレコードが曖昧なままAPIを増やすと、同期そのものが運用負債になります。
見積番号や受注番号の採番ルールも同じで、SFA発番なのかERP発番なのかが曖昧だと、再送時の重複防止まで崩れます。
認証と権限も分けて考えたいところです。
営業に必要なのは、工場の生産計画そのものではなく、納期回答や在庫可用性の結果です。
OAuthなどでAPI認証を整えつつ、SFA側には必要最小限の項目だけ返す形にすると、権限設計が整理されます。
価格、原価、利益率、在庫引当のように見せる範囲を誤ると、使う人が増えるほど運用が荒れます。
運用フェーズでは、データ品質KPIと連携保守を別立てで持つと安定します。
顧客や品目の重複率、必須項目の登録率、見積から受注への変換失敗率、在庫照会APIのエラー件数、例外キューの滞留件数を追うと、どこで詰まっているかが見えます。
監視を入れずに連携だけ作ると、障害を最初に検知するのが営業になりがちです。
例外処理の担当をRACIで切り、再送条件やエスカレーション先を決めておくと、保守の属人化を避けられます。
受発注システム中心の強みと弱み

受発注システム中心のアプローチは、営業管理よりも注文処理の摩擦を減らすことに軸があります。
TOPPANが受発注DXの文脈で整理している通り、FAXやメールで受けた注文を人が読み替えて入力する運用は、入力工数だけでなく、問い合わせ対応と転記ミスも生みます。
ここにBtoB受発注システムやEDI、場合によってはRPAを組み合わせると、注文書の受領から登録までの流れを詰められます。
この方式が向くのは、注文の頻度が高く、品目や価格のルールが比較的定型で、営業案件というよりルーチン受注の比率が高い企業です。
既存顧客からの反復注文が多い部材メーカーや消耗品系では、受注入力と問い合わせの負荷が下がるだけでも効果が出ます。
営業が案件を育てるというより、注文処理をいかに止めないかが勝負の領域では、SFAより先に効くことがあります。
弱みははっきりしていて、案件化前の動きや受注見込み、失注理由、案件ごとの競争状況は取りにくいことです。
つまり、営業予測をつくる基盤にはなりません。
既存注文の処理を磨くには向いていても、新規開拓や大口案件の進捗管理、見積から受注までの勝ち筋分析は別の仕組みが要ります。
受発注システムだけで営業DX全体を語ると、注文後の効率化に話が寄り、受注前の改善余地が見えなくなります。
企業規模やフェーズで見ると、まずFAX削減と注文入力効率を狙う段階なら、受発注システム中心の着手は筋が通ります。
営業部門の案件管理がまだ成熟しておらず、まず受注センターや営業事務の負荷を下げたい企業には合います。
ただし、その先で納期回答や在庫引当まで精度を求めると、結局は販売管理やERPとの接続が必要になります。
受発注画面だけが新しくても、裏で人手確認が残っていれば、処理の入口が変わっただけで全体のリードタイムは縮みません。
ℹ️ Note
[!TIP] 判断基準をざっくり置くなら、営業予測と案件管理を先に整える段階ではSFA単体、納期回答や受注後処理まで一気通貫で整える段階ではSFA+ERP/販売管理連携、FAX削減と注文入力効率を優先する段階では受発注システム中心、という切り分けが実務ではぶれにくい設計です。
実装時の注意点は、この方式でも変わりません。
顧客、品目、価格のマスタ統合、認証と権限、データ品質KPI、監視と例外処理が抜けると、注文が増えるほど運用が崩れます。
受発注中心は短期効果が見えやすいぶん、周辺設計を後回しにしがちですが、そこで止めると「入力は減ったが、納期回答と価格確認は相変わらず人が追う」という中途半端な状態が残ります。
製造業では、どの方式を選ぶにしても、営業画面の見た目より、裏側のデータと業務責任のつながりで差が出ます。
製造業の営業DX事例から学ぶ、Before/Afterの見方

事例データ
公開事例の数字を見るときは、まず「どの工程を変えた結果の数値か」を切り分けると読み解きやすくなります。
営業DXの成果は、営業画面の刷新だけで生まれるものと、見積、承認、在庫回答、受注後処理までつないだことで生まれるものが混在しているからです。
たとえばSansanの『製造業にSFAが必要な理由とは?導入メリットや選び方・成功事例を解説』では、予測誤差を30%から10%へ縮める目標例が示されています。
ここで見るべきなのは、単に予測モデルの精度だけではなく、案件定義の統一と入力の継続が前提になっている点です。
MAPEは実績値に対する予測誤差率を見る指標なので、案件の更新が止まっている組織では数字だけ整えても意味を持ちません。
実務では、案件ステージの定義がぶれているだけで予測は崩れます。
失注率や受注率の改善は、営業プロセスの標準化に近い文脈で語られることが多いです。
Kiyonoが紹介するSFA活用例では、失注率が約10%削減し、受注率が15%向上したケースが示されています。
この種の数値は、案件の追い方がそろい、停滞案件の可視化が進み、見積後のフォロー漏れが減った結果として理解すると腹落ちします。
逆に言えば、案件管理を入れても見積提出までの時間や承認待ちが見えないままだと、同じ水準の改善は出にくい設計です。
受注後まで含めた効果としては、Inodayが紹介するNetSuite関連事例の、Order-to-Cashを14日短縮、エラー率を8%改善、18カ月で3.8x ROIという数字が参考になります。
これは営業DXというより、受注から請求までのプロセス全体を整流化した結果として読むべき事例です。
営業部門だけで完結する施策ではなく、受注登録、在庫・出荷、請求処理の手戻りをどこまで減らしたかが効いています。
物流側の公開事例も、営業DXの読み方に示唆があります。
Hacobuが紹介する物流の2026年問題と2025年にすべきことでは、日本製紙が全国12工場で改善を進め、2時間超の拠点滞在車両を年間約98%削減した事例が示されています。
営業KPIそのものではありませんが、待機というムダ時間を部門横断で計測し、改善対象を共通言語化した点は同じです。
営業から見ると納期回答の遅れ、生産から見ると段取りの乱れ、物流から見ると車両待機という別々の問題でも、横断KPIに載せると一本の流れとして扱えます。
数字を並べるときは、工程ごとの性質の違いも押さえておきたいところです。
予測精度改善は案件入力と会議運営の品質、失注率削減と受注率向上は営業行動と案件管理の標準化、OTC短縮やエラー率改善は基幹連携と受注後プロセスの設計が主因になりやすいのが利点です。
同じ「営業DXの成果」でも、効いているレバーは別物です。
製造業にSFAが必要な理由とは?導入メリットや選び方・成功事例を解説 | 営業DX Handbook by Sansan
製造業にとってSFAは、営業活動を効率化し生産性を高めるために欠かせません。正しくSFAを活用することで、自社の売上アップにつながります。この記事では、製造業を営む企業にSFAが必要な理由や導入メリット、選び方や成功事例について解説します。
jp.sansan.com成果の前提条件
公開事例をそのまま自社の期待値に置き換えると、たいてい見積もりが甘くなります。
再現条件を工程単位でそろえないと、SFAの入力負荷だけ増えて終わるからです。
要するに、数値の前にはデータと運用の地ならしがあります。
まず外せないのが、案件や見積の入力定着です。
少なくとも入力定着率が70%以上ないと、失注率や受注率の比較は母集団がぶれます。
案件が登録されていない、更新日が古い、失注理由が空欄という状態では、改善したように見えても観測漏れの可能性が残ります。
予測精度改善の文脈では、この定着率がスタート地点になります。
次に効くのが、商品マスタと価格ルールの整備です。
品目マスタに型番、単位、有効期間、販売可否がそろっていないと、見積の自動化も受注後の整合も崩れます。
顧客別価格キーの運用が曖昧な組織では、営業が都度確認する運用から抜け出せません。
価格の例外条件を個人の記憶で回している限り、承認LTは縮まりません。
承認ルールの明文化も同じくらい効きます。
どの値引き率なら誰が承認するのか、支払条件の例外は誰が持つのか、在庫引当や特注条件の判断はどこまで営業が触れてよいのかが不明確だと、ワークフローだけ入れても滞留先がメールからシステムに移るだけです。
実務では、ダッシュボードで見積提出までの中央値と承認LTの上位10%を並べると、どこが典型的な遅れで、どこが例外処理なのかが一気に分かれます。
この並べ方をすると、現場と管理職の間で改善テーマの合意が早く進みます。
在庫や納期回答を伴う改善では、在庫精度KPIが98%を超えているかも分岐点になります。
SFAからATPを返しても、元の在庫データがずれていれば、回答速度だけ上がって約束精度が落ちます。
ATPは手持在庫、入荷予定、既約束受注を基に約束可能数量を計算する考え方です。
たとえば手持在庫10、当日入荷予定5、既約束受注8なら、当日回答できる数量は7という形で即答できます。
こうした即答は在庫データの信頼性が前提です。
受注後まで伸ばす場合は、受注番号や見積番号の採番ルール、例外時の再送条件、エラー時の責任分担まで含めて決めておく必要があります。
OTC短縮やエラー率改善の事例は、SFA導入単体というより、ERPや販売管理との一気通貫設計の成果として出ていることが多いです。
営業DXを営業部門の施策としてだけ扱うと、この層が抜け落ちます。
Before/Afterの見方

Before/Afterは、単一指標で読むより、工程のつながりが見える形で並べたほうが判断しやすくなります。
失注率だけ下がっても、承認LTや納期回答率が悪化していれば、営業が無理に案件を積んだだけかもしれません。
逆にOTCだけ短くても、予測MAPEが悪いままだと生産計画との接続が弱いままです。
公開事例を事例ベースとして整理すると、比較の軸は次のようになります。
| 指標 | Before | After | 観測期間 | データ出所 |
|---|---|---|---|---|
| 予測誤差 | 30% | 10% | — | Sansan掲載の製造業向けSFA解説 |
| 失注率 | 約10%削減前 | 約10%削減後 | — | Kiyono紹介のSFA解説 |
| Order-to-Cash日数 | 短縮前 | 14日短縮後 | 18カ月ROI観測 | Inoday掲載のNetSuite関連事例 |
| 受発注エラー率 | 改善前 | 8%改善後 | 18カ月ROI観測 | Inoday掲載のNetSuite関連事例 |
| 投資対効果 | 導入前 | 3.8x ROI | 18カ月 | Inoday掲載のNetSuite関連事例 |
| 2時間超の拠点滞在車両 | 改善前 | 年間約98%削減後 | 年間 | Hacobu掲載の日本製紙事例 |
この表でポイントになるのは、列を埋めることではなく、比較対象をそろえることです。
たとえば一次納期回答率を見るなら、見積依頼受領から最初の回答返却までをどう定義したかを固定する必要があります。
工程別リードタイムも、引合から見積提出、見積提出から承認、承認から受注登録というように区間を分けないと、どこで縮んだのか分かりません。
実務で運用するなら、公開事例の数字に自社の観測指標を重ねる形が使いやすいのが利点です。
具体的には、工程別リードタイム、一次納期回答率、受発注エラー率、予測MAPE、失注率、受注率、承認LTの上位10%を横並びにします。
中央値と上位10%を両方置くと、通常運転の速さと例外処理の重さが同時に見えます。
平均値だけだと、少数の重い案件に引っ張られて改善テーマがぼやけます。
ℹ️ Note
[!TIP] Before/Afterで強いのは、単一の成功数字ではなく、同じ観測期間で複数KPIがどう連動したかです。営業の数字だけでなく、生産や物流の待ち時間まで同じ期間で並べると、部分最適か全体最適かの見分けがつきます。
製造業では、営業から生産、物流までの連なりが長いため、公開事例の数字は「その会社がどこまで横断設計できていたか」を読む材料として使うと実践的です。
失注率削減と受注率向上だけを追うより、予測精度、承認速度、納期回答、OTC、物流待機までつないで見るほうが、再現可能な改善像が浮かび上がります。
よくある失敗と、SFAが定着しない企業の共通点

失敗のパターン
SFAが定着しない企業には、似たつまずき方があります。
いちばん多いのは、目的が曖昧なまま導入が先に進み、いつの間にか「SFAを入れること」自体がプロジェクトのゴールになっている状態です。
こうなると、営業日報の置き換えや案件一覧の可視化までは進んでも、受注サイクルのどこを縮めたいのかが決まっていないため、現場では入力負荷だけが増えます。
製造業向けにSFAの論点を整理した目標設定とPDCAの有無が成果を分ける前提として扱われています。
要するに、案件管理画面が整っても、改善テーマが定義されていなければ運用は続きません。
次に多いのが、現場不在の設計です。
情報システム部門や管理職だけで項目設計や承認フローを決めると、営業が商談中に必要な情報、生産計画が確認したい情報、物流が納期回答に必要な情報が噛み合わなくなります。
製造業では営業だけで受注が完結しないため、このズレがそのまま二重入力や持ち帰り確認につながります。
見積、在庫、受注、生産指示まで含めて業務フローを最適化する視点が欠かせません。
SFA単体の画面設計だけで終えると、後工程との接続で詰まります。
入力項目を盛り込みすぎる失敗も典型です。
導入初期から理想的なデータモデルを目指して、案件、見積、競合、原価、承認、納期、失注理由まで細かく必須化すると、現場は登録を避けるようになります。
登録されないSFAは分析以前の問題で、結局はExcelやメールが裏の本番環境になります。
とくに製造業では、案件初期の段階で確定していない情報が多いため、未確定情報まで必須にすると入力率が落ちます。
ERPや販売管理とつながっていないケースも、定着失敗の共通点です。
営業側では案件が進んでいるのに、受注後の番号体系や在庫引当、納期回答が別管理のままだと、SFAのデータが後工程に渡りません。
すると営業は「どうせ受注後は別システムでやる」と認識し、SFAが案件メモ置き場になります。
リアルタイムAPIまで一気に作り込まなくても、CSVやバッチ連携で見積番号と受注番号を一意にひもづけるだけで、追跡可能性は一段上がります。
ここが切れている組織は、改善活動を始めても効果測定が途切れます。
KPI未設定も根深い問題です。
案件数、売上見込み、受注率だけを見ていると、どの工程で滞留が起きているのか見えません。
製造業のSFAでは、見積提出時間、承認LT、受注から生産指示までのTAT、予測MAPE、失注率のように工程別のKPIに分けないと、改善対象がぼやけます。
MAPEは実績と予測の差を割合で捉える指標で、予測の質を継続的に観測するのに向いています。
営業会議で受注見込みだけを話し、予測精度を追っていない企業では、生産との接続がいつまでも属人的なまま残ります。
営業以外の部門を巻き込めていないケースも、定着しない企業によく見られます。
営業だけがSFAを入力し、生産管理、見積、物流、経理が従来運用のままだと、納期回答や承認の遅れが改善しません。
現場では「入力したのに返事が早くならない」という不満が出て、SFAへの協力が止まります。
営業DXなのに営業部門だけで閉じている状態は、製造業ではほぼ確実に壁になります。
導入から3ヶ月前後で急につまずく会社では、承認ルールが例外だらけになっていることも多いです。
標準フローはあるのに、顧客別価格、特注品、支払条件、短納期案件ごとに個別判断が増え、結局はメールや口頭確認に逆戻りします。
DX推進の現場では、この段階で「システムが使いにくい」と評価されがちですが、実際にはルールの粒度が揃っていないことが原因である場面が少なくありません。
例外申請をテンプレート化し、月次で例外理由を集約すると、属人的だった判断基準が整理され、回復の糸口が見えます。
対策と運用ルール

立て直しの起点は、目的を機能ではなく工程で定義し直すことです。
案件を見える化したい、入力を統一したい、といった抽象的な目的ではなく、見積提出までの時間を詰めるのか、承認LTを短くするのか、受注から生産指示までの受け渡しを詰まらせないのかを、初月の段階で決めます。
そのうえで工程別KPIと改善テーマを定義し、四半期ごとに見直す運用にすると、導入が目的化しにくくなります。
設計段階では、営業だけでなく見積、生産計画、物流の代表を入れた運営委員会を置くのが有効です。
週次または隔週で、入力項目、承認ルール、連携エラー、納期回答の詰まりを一つずつ潰していく形です。
ここで役立つのがRACIの考え方で、誰が実行責任を持ち、誰が最終承認し、誰に相談し、誰に共有するかをタスクごとに切っておくと、例外時の迷子が減ります。
SFA運用が止まる企業は、ツールの権限設定よりも先に責任分担が曖昧なことが多いです。
入力項目は、初期から網羅を狙わないほうが定着します。
案件登録、見積発行、受注連携の核になる最小必須項目だけに絞り、まずは10〜15項目で回す設計が現実的です。
顧客名、品目、数量、希望納期、案件金額、見積番号、確度、失注理由のように、後工程や分析で本当に使う項目だけを残します。
定着後に、競合情報や詳細な商談属性を追加したほうが、入力率もデータ品質も落ちにくくなります。
ERPや販売管理との接続では、いきなり完璧なリアルタイム統合を目指さなくても構いません。
優先順位は、見積番号と受注番号の一意連携です。
CSVでも夜間バッチでも、SFA側の見積が受注にどう変わったか追える状態を先につくると、営業から生産への受け渡しが見えるようになります。
バッチ連携では日中の変化を逐次追えないため、在庫回答の即時性には限界がありますが、識別子の接続ができていれば、少なくともどこで情報が切れたかは特定できます。
連携が弱い企業ほど、まず番号体系の整備で効果が出ます。
KPIは経営ダッシュボード用と現場運用用を分けず、同じ画面で工程別に並べるほうが機能します。
見積提出時間、承認LT、受注から生産指示までのTAT、予測MAPE、失注率をひとつのダッシュボードに置くと、営業会議が感覚論に戻りにくくなります。
平均値だけでなく、中央値と遅延案件の分布を見る運用にすると、通常案件と例外案件が混ざりません。
部門巻き込み不足への対策としては、納期回答のSLAを営業と生産の共同KPIにする設計が効きます。
営業だけに回答責任を持たせても、在庫や生産計画の情報がなければ返答できません。
逆に生産側だけが守っても、営業が必要情報を揃えなければ遅れます。
共同KPIにして、目標とインセンティブを連動させると、入力漏れや確認待ちが部門間の押し付けになりにくくなります。
承認ルールの例外処理も、運用ルールとして標準化しておくべきです。
値引き、支払条件、特注対応、短納期案件など、例外が起きる領域は最初から決まっています。
ここを「都度相談」で流すのではなく、例外申請テンプレートを用意し、月次で例外内容を見直して標準ルールに吸収していくと、3ヶ月目の失速を避けやすくなります。
SFAが定着する企業は、標準フローだけでなく、例外の扱い方まで運用に落としています。
⚠️ Warning
定着しない原因を「現場が入力しないから」と片づけると改善が止まります。実際には、目的、責任分担、例外処理、番号連携、共同KPIのどこかが欠けており、入力しないのは結果として表面化しているだけ、という順番で捉えたほうが修正点を見つけやすくなります。
3ヶ月で立て直すチェックリスト

導入後の失速は、設計思想を全部やり直さなくても立て直せます。3ヶ月での回復は、対象を絞って順番に直すことが前提です。チェックポイントは次の通りです。
- SFA導入の目的を機能名ではなく工程名で定義し直し、初月に工程別KPIと改善テーマを明文化している
- KPIとして、見積提出時間、承認LT、受注から生産指示までのTAT、予測MAPE、失注率をダッシュボード化している
- 営業だけでなく、見積、生産計画、物流の代表を含む運営委員会を週次または隔週で回している
- 入力項目を最小必須に絞り、初期運用を10〜15項目で成立させている
- ERPまたは販売管理と、見積番号・受注番号の一意連携ができている
- CSVまたはバッチ連携でも、SFAの案件と受注後データを追跡できる状態になっている
- 承認ルールの例外をテンプレート化し、月次で例外理由を集約して標準ルールへ反映している
- 営業と生産の共同KPIとして、納期回答のSLAを設定している
- 目標値だけでなく、SLA未達時のエスカレーション先と責任分担を決めている
- 営業以外の部門が「閲覧者」ではなく、KPIと運用ルールの当事者として参加している
このチェックリストで抜けが多い企業ほど、SFAを現場の努力で支えようとして疲弊します。
逆に、項目数を減らし、番号をつなぎ、例外処理を標準化し、部門横断の会議体を回せるようになると、案件管理ツールだったSFAが、受注サイクル改善の運用基盤に変わっていきます。
製造業の営業DXでは、その変化が起きた時点で、ようやく定着の土台ができたと判断できます。
まず何から始めるべきか

製造業の営業DXは、ツール選定から始めるより、まず自社の受注サイクルを工程として見える化するところから着手したほうが前に進みます。
特に、見積提出時間、承認時間、受注から生産指示までの時間を実測すると、どこに待ち時間が溜まっているかがはっきりします。
現場では「一気通貫で全部つなぐ」構想が出がちですが、実際には業務インパクトが最も大きい1工程から動かしたほうが定着しやすく、最初の成功が営業・生産・情シスの信頼をつくります。
動き出しの基準は、全体最適の理想像ではなく、最初に削れる滞留を見つけられるかどうかです。
ITコンサルティングファーム出身。営業DX推進プロジェクトをリードし、SFA/CRM/MAの統合設計とAI活用による営業プロセス自動化を専門としています。
関連記事
AIトレーニングデータの作り方と社内ガバナンス設計
AIトレーニングデータの作り方と社内ガバナンス設計
社内データをAI学習に使う話は、モデル選定より前にデータの作り方と運用の回し方を同時に決めないと、現場で止まります。DX推進の現場では、評価データの汚染、重複の多さ、ラベル基準の不統一が後工程で効いてきて、学習よりも再整備に時間を取られるケースが繰り返し発生しています。
SFA活用事例7選|営業成果の共通点と再現条件
SFA活用事例7選|営業成果の共通点と再現条件
SFAは、導入しただけでは営業成果につながりません。営業現場では入力が増えて疲弊し、そのまま使われなくなる流れが繰り返されがちですが、実際に運用してみると、入力項目を絞り込み、マネージャーが会議でそのデータを使い切る形までそろったときに定着率は一気に変わります。
営業DXの進め方|成功事例とツール活用のポイント
営業DXの進め方|成功事例とツール活用のポイント
営業DXは、SFA(営業支援ツール:商談・活動・案件管理を可視化するツール)やCRM(顧客関係管理:顧客情報と接点履歴を一元管理する仕組み)を入れれば前に進む話ではありません。現場では、最初に決めるべき入力項目と運用ルール、そして責任者が曖昧なまま導入が始まると、データが揃わず定着も止まりがちです。
営業DXとは?デジタル化との違いと進め方
営業DXとは?デジタル化との違いと進め方
営業DXは、紙をExcelに置き換えたりSFAを入れたりして終わる話ではありません。データとデジタル技術を使って、営業プロセスそのものと役割分担、KPI運用まで組み替え、受注の再現性を上げていく取り組みです。