BtoB-EC導入の稟議が通らない理由と、通る会社がやっている経営説明の作り方

BtoB-EC導入の稟議が通らない理由と、通る会社がやっている経営説明の作り方B2B-EC
この記事は約13分で読めます。

この記事でわかること
BtoB-EC導入の稟議が止まる場面は決まっています。「費用が高い」「本当に必要か」「リスクが不明」——経営層から返ってくるこれらの反応は、説明の中身ではなく「説明の軸」が間違っていることのサインです。本記事では、稟議が止まる原因と、経営層・各部門に響く説明の作り方を整理します。読み終えると、稟議資料の骨格が見えてきます。

堀川 治(株式会社サンクユー 代表取締役)
「良い提案なのになぜ通らないのか」という相談を受けることがあります。原因はほぼ共通しています。担当者が「システムの話」をしているのに対して、経営層が聞きたいのは「経営の話」です。この軸のずれを直すだけで、稟議の通過率は変わります。

稟議が止まる3つの典型パターン

稟議が通らない場面を分析すると、ほぼ3つのパターンに収束します。

パターン典型的な状況経営層の反応
機能説明から始める「顧客別価格が設定できます」「在庫連携が可能です」という説明から入る「それは便利そうだが、本当に必要か?今のやり方では駄目なのか?」
費用だけを提示する初期費用○○円・月額○○円という数字だけを出す「高い。それに見合う効果があるのか説明してほしい」
メリットだけを並べる「業務が効率化されます」「ミスが減ります」という定性的な説明「具体的にどれくらい?根拠は?今でも何とかなっているのでは?」

共通しているのは、「システムの話」を「経営の話」として説明できていないことです。経営層が承認を出すのは「この投資が事業にとって合理的だ」と判断した時です。機能の説明ではその判断ができません。

経営層に響く説明の基本フレーム

稟議を通すための説明は、以下の順序で組み立てます。機能の話は最後まで出してきません。

  1. 1

    現状の問題を数値で示す

    「今、何にどれだけのコストがかかっているか」を金額・時間・件数で示す。感覚的な「大変です」ではなく、計測された数値で提示する。

  2. 2

    現状維持のリスクを示す

    「何もしなかった場合に何が起きるか」を示す。現状維持は安全ではなく、コストと機会損失が積み上がり続けるリスクがあることを伝える。

  3. 3

    投資対効果(ROI)で説明する

    「いくら投資して、何年で回収できるか」を示す。効果が不確かな部分は保守的な数値で計算し、根拠を明示する。

  4. 4

    事業戦略との整合性を示す

    「この投資が中長期の事業方針とどう整合するか」を示す。単なる業務改善ではなく、事業基盤の強化であることを伝える。

  5. 5

    意思決定の重さを下げる

    段階導入・フェーズ分けを示すことで「全額を一括でコミットしなくてもよい」という選択肢を提示する。承認のハードルが下がる。

稟議を通す7つの説明ポイント

① 現状コストを数値で可視化する

稟議を通す最初のステップは「現状の問題を数値化する」ことです。数値がなければ「改善幅」を示せず、ROIの計算もできません。

計測すべき項目と計算例です。

計測項目計測方法計算例
受注処理時間1件あたりの処理時間 × 月間件数10分/件 × 1,000件 = 月167時間 → 年2,000時間
受注処理の人件費処理時間 × 時間単価年2,000時間 × 3,000円 = 年600万円相当
入力ミス・確認作業月間のミス件数 × 修正対応時間月20件 × 30分 = 月10時間の修正対応
FAX・電話対応時間1件あたりの対応時間 × 件数5分/件 × 500件 = 月42時間
実務メモ
数値を出す前に「今の受注処理、1件あたり何分かかっているか」を担当者にヒアリングすることから始めてください。この数字を出したことがない会社は多い。数字を出した瞬間に、担当者自身が「これはまずい」と気づくケースもあります。

② 機会損失を金額換算する

受注処理に時間が取られている担当者は、その時間を新規開拓や既存顧客フォローに使えていません。これは「やっている業務のコスト」ではなく「できていない業務の損失」です。

機会損失の換算方法の例です。

  • 営業担当者が受注処理に月40時間使っている場合、その40時間を営業活動に使えれば月に何件のアポ・商談が追加できるか
  • 新規開拓1件の平均受注額が○○万円なら、月○件の機会損失は金額に換算するといくらか
  • 既存顧客フォロー不足による解約・取引縮小が月に何件発生しているか

機会損失は推計になりますが、「保守的な数値で計算する」ことが重要です。過大な数字を出すと信頼性が下がります。「この計算は保守的な見積もりです」と明示した上で提示します。

③ 人的リスクを経営リスクとして示す

受注業務が特定の担当者に依存している場合、それは業務リスクではなく経営リスクです。

  • 退職リスク:担当者が退職した場合、価格交渉の履歴・顧客ごとの特例条件・イレギュラー対応のルールが失われる。引き継ぎに数ヶ月かかるケースも少なくない
  • 価格ミスリスク:手入力・口頭確認・FAXに依存した受注プロセスは、価格ミス・数量ミスが発生しやすい。取引先への影響が大きいほど、1件のミスが与信・関係悪化につながる
  • スケールのボトルネック:受注件数が増えたとき、担当者の工数を増やさないと対応できない構造は、事業成長の上限を人手で規定している状態

これらは「担当者が大変そうだから改善する」という話ではなく、「このリスクが顕在化した時のビジネスインパクト」として提示します。

④ 費用をROIで説明する

「初期費用○○円」だけを提示すると、経営層は「高い」という反応になります。費用は必ず効果とセットで提示します。

ROI計算の構成例です。

項目内容金額(例)
投資
初期構築費用設計・開発・テスト・導入500万円
年間保守費用月額保守・ホスティング60万円/年
効果(年間)
受注処理工数削減年2,000時間 × 削減率60% × 時間単価3,000円360万円/年
ミス対応コスト削減修正・クレーム対応の工数削減50万円/年
機会損失改善(保守的)営業時間の回復による受注増加100万円/年
合計効果510万円/年
回収期間初期費用500万円 ÷ 年間効果510万円約1年
注意:ROI計算は根拠が重要です。「60%削減」という数字の根拠(比較事例・自社試算の前提)を示さないと、数字だけが一人歩きして信頼性が下がります。保守的な前提で計算し、「この計算の前提はこうです」と明示する方が説得力があります。

⑤ 事業戦略との整合性を示す

経営層が承認しやすいのは「単なる業務改善」より「事業の方向性に沿った投資」です。BtoB-ECが自社の中長期方針とどう整合するかを示します。

  • 取引先の拡大:現在の受注体制では対応できる取引先数に上限がある。BtoB-ECにより、担当者を増やさずに取引先を増やせる体制を作る
  • 人手不足への対応:今後の採用難・人件費上昇を見越して、受注処理の自動化を今のうちに進める
  • 競合・業界の変化:同業他社や取引先が発注のデジタル化を進めている場合、対応できない企業は取引から外れるリスクがある
  • データ活用:受注データが蓄積・分析できるようになることで、在庫計画・営業戦略への活用が可能になる

⑥「やらないリスク」を提示する

稟議の場では、導入した場合のメリットだけでなく「導入しなかった場合に何が起きるか」を提示します。現状維持は「何も変わらない」ではなく「コストと機会損失が積み上がり続ける」状態です。

やらないリスク具体的な影響時間軸
人件費の増加受注件数増加に対応するため、担当者の追加採用が必要になる1〜2年後
属人化の深刻化担当者の負担が増え、退職リスクが高まる。引き継ぎコストが拡大する常時リスク
取引先要望への対応遅れ取引先が発注の効率化・デジタル化を求めてきた時に対応できない1〜3年後
機会損失の固定化営業担当者が受注処理に使う時間が減らず、新規開拓・フォロー不足が続く継続中

⑦ 段階導入で意思決定の重さを下げる

「全額コミット」を最初に求めると、承認のハードルが上がります。段階導入を提示することで「まず小さく始めて、効果を確認してから拡張する」という意思決定が可能になります。

  • フェーズ1:主要取引先・主要商品の受注自動化(初期費用の抑制、早期のROI確認)
  • フェーズ2:全取引先への展開・基幹連携の強化(フェーズ1の効果確認後に判断)
  • フェーズ3:分析機能・高度化(事業成長に合わせて追加)

「まずフェーズ1の○○万円だけ承認してほしい」という提案は、「全部で○○万円」よりも通りやすい。効果が出れば後続フェーズの承認も得やすくなります。

部門別:何を・どう説明するか

稟議の承認には複数部門の合意が必要です。部門によって「何が重要か」が異なるため、説明の軸を変えます。

部門関心事響く説明の軸想定される反対意見と対応
経営層投資対効果・リスク管理・事業戦略ROI・回収期間・やらないリスク・中長期の事業整合性「費用が高い」→ 回収期間と年間効果をセットで提示。「本当に必要か」→ 現状コストと機会損失を数値化して提示
営業部門自分の業務への影響・追加負荷への懸念受注処理時間の削減・提案・フォロー時間の増加・操作の簡便さ「覚えることが増える」→ 取引先が自分で入力するので担当者の作業は減る。「今のやり方に慣れている」→ 移行期間・サポート体制を示す
管理部門ミス削減・処理の正確性・請求業務への影響入力ミス削減・自動照合・請求データの自動生成・監査証跡「基幹との連携は大丈夫か」→ 連携設計の具体的な方針を示す。「移行時のデータはどうなるか」→ 移行計画と検証方法を示す
情シス部門セキュリティ・保守体制・既存システムとの整合性セキュリティ設計・保守体制・ERP連携方式・障害時の対応フロー「保守の体制はどうなるか」→ ベンダーの保守SLA・対応範囲を提示。「既存システムへの影響は」→ 連携の疎結合設計を説明

稟議資料に入れるべき項目

上記の説明ポイントを資料に落とし込む際の構成例です。

  • 現状課題の整理:受注処理コスト(時間・金額)、ミス発生件数、属人化の状況を数値で記載
  • 課題を放置した場合のリスク:人件費増加・退職リスク・機会損失の継続を時間軸付きで記載
  • 提案概要:何を導入するか(機能一覧ではなく「何ができるようになるか」で記載)
  • 費用と効果:初期費用・年間費用・年間削減効果・回収期間をROI計算で提示
  • 段階導入計画:フェーズ1〜3の内容・費用・スケジュール概要
  • リスクと対策:導入リスク(移行・取引先対応・連携)と各対策を記載
  • ベンダー選定の根拠:なぜこのベンダー・このシステムを選ぶのかの判断軸
  • 次のステップ:承認後に何から始めるか、次の意思決定ポイントはいつかを明示
資料作成のポイント:稟議資料は「承認者が次の人に説明できる資料」である必要があります。承認者が取締役会や他の役員に説明する場面を想定し、「その人が資料だけを持って説明できるか」を確認してください。

稟議用のたたき台資料、一緒に作ります

「現状コストの数値化」「ROI計算の組み立て」「部門別の説明軸の整理」——これらを御社の状況に合わせて整理するお手伝いをしています。稟議を通すための資料構成のご相談も歓迎です。

稟議資料の相談・無料ヒアリングを申し込む

よくある質問

現状コストの数値が正確に出せない場合はどうすればいいですか?

完璧な数値でなくても構いません。担当者へのヒアリング(「1件の受注処理に何分かかっているか」「月に何件ミスが発生しているか」)で得た概算値と、その前提を明示することで十分です。「この数値は○○ヶ月の担当者ヒアリングによる概算値です」と根拠を示した上で提示する方が、「大変です」という定性表現より説得力があります。

ROI計算で「効果」の数値はどう設定すればいいですか?

保守的な数値で計算することを推奨します。「工数が80%削減される」より「40%削減される前提で計算した」の方が信頼性があります。過大な効果を示して後から実現できなかった場合のリスクの方が大きい。「保守的な前提でもこれだけ回収できる」という計算の方が稟議の場では強い説得力を持ちます。

情シス部門が「保守・運用体制が不明」と言って承認しません。どう対応すればいいですか?

ベンダーの保守SLA(対応時間・対応範囲・月額費用)を具体的に提示することが必要です。「問題が起きたらどこに連絡して、何時間以内に対応してもらえるか」「バージョンアップはどう対応するか」「障害時の代替運用はあるか」を確認した上で資料に盛り込んでください。情シスの懸念は「何かあった時の責任の所在が不明」であることが多い。明確にすることで解消できます。

「まず小さく始めたい」と言っても、経営層に「どうせ後でお金がかかるんじゃないか」と言われます。

正当な懸念です。「段階導入は後から追加費用が膨らむのではないか」という疑問には、「フェーズ2・3の概算費用とスケジュール」を最初から提示することで対応します。「今は○○万円、将来全体でトータル○○万円になる前提」と全体像を示した上で「まずフェーズ1から始める」という提案にすると、経営層も判断できます。段階導入の費用感を隠すと信頼性が下がります。

稟議が通る説明の組み立て、現状コストの数値化——ご相談ください

「何から数値化すればいいかわからない」「ROI計算の組み立てに自信がない」「部門別の反対意見への対応に詰まっている」——稟議を通すための準備段階からお手伝いします。

無料相談・稟議サポートを申し込む

投稿者プロフィール

OSAMU HORIKAWA
OSAMU HORIKAWACEO
株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。

関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。

この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。

その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現(退任時:常務取締役)。

2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。

単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。

NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution

■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム(富野由悠季)
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン

お気軽にご相談ください

お気軽にご相談ください

タイトルとURLをコピーしました