なぜBtoB EC・受発注の導入は「誰も使わない発注サイト」という失敗に陥るのか
BtoB EC・受発注システムを導入したにもかかわらず、得意先の大半が結局FAXや電話で発注し続ける事例は少なくありません。この失敗の多くは製品選びの問題ではなく、「どの受注経路を、どの順番で、どこまでデジタル化するか」という問いに答えないまま選定を進めたことに起因しています。
製品デモの画面が使いやすそうに見えて「これなら得意先も使ってくれるはず」と判断する流れは、自社側の都合だけで導入を決めているサインです。本記事では、製品比較に入る前の「要件整理」の進め方を解説します。
「受注経路の構造」をどう分解するか
BtoB EC・受発注の導入動機は「受発注をデジタル化したい」という表現で語られることが多いですが、それだけでは要件になりません。以下の問いで受注経路を分解してください。
- 現在、受注はFAX・電話・訪問・メール・既存EDIのどの経路で、それぞれ何割を占めているか
- 受注データの入力から出荷指示までに何分・何時間かかっており、誰が転記しているか
- 受注ミス（数量・品番違い）や欠品トラブルは月に何回発生しているか
- 得意先ごとに発注の仕方（担当者の裁量・発注書式）がどれだけばらついているか
この問いに答えられると、「デジタル化のゴール」と「現状の非効率の場所」が具体化されます。デジタル化によって確実に削減できるのは「受注データの手入力・転記工数」です。一方で「売上が上がる」「得意先満足度が上がる」は条件が揃えば得られる効果であり、必ず実現するとは言えないことを前提に要件を立ててください。
基幹・在庫連携の現状をどう棚卸しするか：現実の制約を先に知る
要件整理で欠かせないのが、現在の基幹システム・在庫管理との連携状況の棚卸しです。以下の項目を確認してください。
- 基幹システム（販売管理・生産管理）の種類と、外部連携用のAPIやCSV出力機能の有無
- 在庫情報がリアルタイムで見えているか、それとも日次更新や目視確認に頼っているか
- 既存EDIやオンライン発注サイトを一部の得意先とすでに使っているか
- 情報システム担当者や外部ベンダーとの窓口が社内にいるか
この棚卸しによって、選択できる戦略パターンが自然に絞られます。例えば基幹システムに外部連携APIがなく、情報システム担当者も不在なら、フルスタックの基幹統合連携は現実的な選択肢になりません。
戦略パターンの候補をどう選定し、仮置きすべきか
BtoB EC・受発注カテゴリには複数の「解き方」があります。製品名を先に検討するのではなく、まずどの戦略パターンに近いかを仮置きしてください。
- 「クラウド受発注サイト即時導入」：情報システム担当が薄い環境で、まず一部得意先からオンライン受注を試したい
- 「基幹システムフル連携構築」：受注データの二重入力・在庫のズレを根本的になくしたい
- 「既存EDI・電子帳票の拡張活用」：すでに大口得意先とEDIを使っており、対象を広げたい
- 「FAX・電話併存の段階移行」：得意先の大半がFAX発注に慣れており、一斉移行が現実的でない
- 「アウトソース型受注代行の活用」：自社に受注入力の専任リソースを割けない
- 「現状体制の維持・人員増強」：件数規模がシステム投資に見合わず、人手対応で足りる
この仮置きは後で変わっても構いません。「現時点では○○パターンが近そう」という仮説を持った状態で製品比較に入ることで、評価軸がブレにくくなります。
Must条件とWant条件をどう比較し、分離するか
要件整理の次のステップは、条件の優先順位付けです。すべての要件を同列に扱うと、機能数が多いだけの製品が評価されがちになります。
Must条件は「これがないと得意先が離反する・業務が成立しない」もの。例えば「既存基幹システムとのデータ連携が可能なこと」「得意先ごとの掛け率・専用価格が設定できること」などです。Must条件は5個以内に絞るのが目安で、それ以上あると「実は全部Wantだった」可能性があります。
Want条件は「あると良いが、なくても導入の判断は変わらない」もの。評価時の加点要素として使います。
得意先の移行負担を評価軸に入れるべき理由と典型的な失敗事例
BtoB EC・受発注カテゴリに固有の論点として、「得意先側の移行負担」があります。自社の業務効率だけを基準にすると、得意先が使いこなせず旧来の経路に戻ってしまうリスクを見落とします。
- 得意先の担当者の年齢層・ITリテラシーにばらつきがあるか
- 発注担当者が変わった際の再教育コストをどちらが負うか
- 得意先専用の画面・価格表示など、個社対応がどこまで必要か
これらを要件整理の段階で確認しておくと、「自社にとって理想の製品」と「得意先が実際に使える製品」のギャップを事前に把握できます。
「買わない条件」とは何か、なぜ先に定義すべきか
要件整理の最後に必ず行うべきステップが、「このBtoB EC・受発注カテゴリで新しいシステムを買わない条件」の定義です。この判断は稟議の通し方や3年トータルコストの見積もりとも関わるため、意思決定の観点を合わせて確認しておくと精度が上がります。
以下のいずれかに該当する場合、追加システムを買わずに済む可能性があります。
- 受注件数が少なく、現状の人員体制でFAX・電話受注を処理しきれている
- 既存EDIやオンライン発注サイトで、主要な得意先の発注は既にカバーできている
- 受注ミスや工数の問題より、在庫データそのものの精度に課題がある
「既存の体制で解決できるなら買わない」という条件を先に定義しておくことで、製品比較の段階で判断軸がぶれなくなります。
要件整理の成果物として持つべきもの（費用感の仮置きを含む）
製品比較に移る前に、以下を整理した状態にしてください。
- 現状の受注経路とその件数比率（FAX・電話・EDI・その他）
- 基幹システム・在庫管理との連携要否と連携方式
- 仮置きした戦略パターンと、その理由
- Must条件（5個以内）とWant条件のリスト
- 得意先の移行負担の見立てと「買わない条件」の定義
これらが揃った状態で比較表を作ると、評価が「どの製品が機能豊富か」ではなく「どの戦略パターンで解くと自社と得意先の双方に合うか」という問いに変わります。
関連記事
- 比較段階の論点整理：【BtoB EC・受発注・比較】製品名でなく「戦略パターン」で比較する方法
- 導入の意思決定を固める：導入の意思決定：稟議の通し方・3年トータルコスト・買わない条件