施策名ではなく、経営判断の詰まりから始める
営業組織改革は、営業戦略、ターゲット、アカウントカバレッジ、商談プロセス、マネジメント、評価、スキル、SFA・CRM、顧客・案件データが連動するテーマです。しかしRFPが「営業力強化支援」の一文だけでは、提案各社が得意領域を中心に別の問題を解き、価格も成果物も比較できません。
発注側が完成した解決策を持つ必要はありません。一方で、経営課題、対象顧客・組織、現時点の仮説、変えてはいけない制約、意思決定者、利用可能なデータ、現場参加条件は示す必要があります。RFPは作業仕様ではなく、共同で仮説を検証する契約の境界です。
経営課題
売上不足を人数・行動量だけでなく、市場選択、価値提案、カバレッジ、案件品質へ分解する。
変える判断
重点顧客、案件投資、価格例外、予測コミット、支援配分の判断を変える。
実装単位
診断、営業モデル設計、パイロット、SFA反映、マネジャー定着を一つの波で行う。
確認する証拠
売上だけでなく、案件品質、転換、予測、営業活動構成、現場への定着を検証する。
構想・投資を決める4つの判断基準
個別施策や解決策を検討する前に、経営・業務・データ・実行の整合を確認します。4つの観点が同じ仮説につながって初めて、実行可能な構想になります。
| 判断軸 | 経営が問うこと | 合格状態 | 見逃した場合のリスク |
|---|---|---|---|
| 問題設定 | 仮説を検証し、対象外を決められるか | 市場・顧客・営業モデル・業務・人材・データを構造化する | 得意な施策へ問題を合わせる |
| 実装力 | 設計を現場の行動とシステムに反映できるか | パイロット、管理職運営、SFA要件、教育まで一貫する | 資料は完成しても営業現場が変わらない |
| 知識移転 | 自社が運営できる成果物と能力が残るか | 共同作成、責任者、更新手順、レビュー基準を契約に含む | 支援終了後に元へ戻る |
| 利益相反 | 特定製品・実装の販売と評価が分離されるか | 評価軸、前提、選定理由、推奨外の選択肢を開示する | 製品導入が目的化する |
判断原則：RFPで成果数値を保証させるのではなく、仮説、評価方法、必要データ、双方の責任、意思決定ゲートを合意します。売上は外部要因を受けるため、先行指標と必要能力が整ったとみなす条件を併用します。
実務で分解すべき設計論点
「あるべき姿」を標語で終わらせず、会議、業務、役割、情報、データ、システム、移行の選択肢へ分解します。
課題を営業ファネルだけに閉じない
重点市場、商品競争力、価格、供給制約、マーケティング連携、顧客データ品質も確認します。営業へ責任を集中させず、売上形成に関与する横断能力を対象にします。
営業モデルの選択肢を要求する
地域、業界、顧客規模、商品、ハンター・ファーマー、インサイド・フィールドの組合せを比較し、カバレッジコスト、専門性、顧客体験、管理負荷で評価します。
パイロットの検証条件を明示する
対象チーム、期間、比較基準、必要データ、管理職の役割、現場フィードバック、Go・No-GoをRFPへ含めます。研修受講だけでなく実商談の判断が変わるかを見ます。
成果物の更新可能性を評価する
顧客セグメント、営業プレイブック、ステージ基準、KPI、SFA要件、会議運営が、支援会社なしで更新できる構造かを確認します。PowerPoint納品だけでは定着しません。
構想から定着までの5ステップ
各段階に意思決定ゲートを置き、資料を作った量ではなく、次へ進める根拠が揃ったかで進捗を判定します。
発注目的と経営制約を整理する
成長・収益・重点市場・顧客体験の課題、対象組織、既存施策、意思決定期限を整理します。未検証仮説と事実を分け、候補会社が再構成できる余地を残します。
何を決めるための支援か説明できる
RFPの評価可能な要求を作る
診断観点、期待成果物、パイロット、SFA連携、定着、知識移転、データ取扱い、体制を記載します。作業量の指定より、品質と判断ゲートを明示します。
提案を同じ尺度で比較できる
ケース討議で提案力を検証する
実際の匿名案件・会議・データ課題を提示し、その場で仮説、追加質問、分析、選択肢を議論します。資料の見栄えより、問いの質と現場で実行できる形に具体化する力を見ます。
候補会社の実務チームと進め方を確認した
契約とガバナンスを設計する
成果物、役割、データ、会議、変更、受入、知識移転、終了条件を合意します。固定価格と準委任の適用範囲を、探索と実装の不確実性に合わせます。
双方の責任と変更手順が明確
パイロット後に投資判断する
先行KPI、現場への定着、必要なデータを用意できるか、管理職運営を評価し、全社展開、設計修正、停止を判断します。支援会社の継続ありきにせず、内部能力の状態も確認します。
展開の根拠と残課題が合意される
検討初期から、業務責任者、経営企画、IT・データ担当、現場代表が同じ議論に参加します。論点ごとの決定者と協議者を明確にし、未決事項は課題管理表で追跡します。全社を一度に詳細化せず、価値と依存関係の大きい領域に対象を絞り、業務からデータ・システムまで一連の流れを検証して仮説を更新します。
戦略・業務・データ・システム・移行を切らない
エンタープライズアーキテクチャの使いどころ
営業改革をビジネスアーキテクチャの顧客価値、営業能力、業務、組織として捉え、CRM・MA・ERP・DWHの責任分界までApplication・データアーキテクチャへ接続します。候補会社が一つの層だけでなく、変更影響と移行順序を説明できるかを評価します。
DAMA-DMBOKの使いどころ
顧客、アカウント、案件、活動、商品、組織の定義、責任者、品質ルール、名寄せ、リネージュをRFPに含めます。DMBOKを知識試験にせず、営業判断に必要なデータが誰の責任で維持されるかを設計できるかで見ます。
EAとDMBOKは、成果物を増やすための形式ではありません。今回の意思決定に必要な範囲に絞って適用し、現行・目標・移行状態の差、データの意味と責任、変更の影響を説明できるように使います。フレームワーク名を掲げるだけでなく、責任者、承認権限、更新頻度、品質基準まで定めて初めて運用できます。
会議で決め、現場が使える成果物
成果物は分量の多い完成版文書ではなく、判断の前提、選択肢、責任、移行条件を追跡し、継続的に更新できる設計資産として作ります。
営業改革RFP本文
背景、目的、対象、仮説、要求成果物、体制、データ、パイロット、受入を構造化します。
使いどころ：候補会社へ同じ前提と問いを渡す
提案評価スコアカード
問題設定、専門性、実装、定着、知識移転、利益相反、費用を重み付けします。
使いどころ：価格以外の選定根拠を残す
ケース討議シナリオ
匿名の顧客・案件・会議・データ状況と期待する検討プロセスを用意します。
使いどころ：実際の担当チームの思考と協働を確認する
契約・意思決定ゲート表
成果物、受入基準、双方RACI、変更、Go・No-Go、知識移転を定義します。
使いどころ：探索と実装の不確実性を統制する
よくある失敗と、早期の是正方法
失敗の多くはツールの機能不足ではなく、目的、対象範囲、責任、データ、移行条件の曖昧さから起きます。
| 失敗パターン | 構造的な原因 | 是正する方法 |
|---|---|---|
| 解決策をSFA導入に固定する | 営業モデルと管理職運営の課題を検証していない | 変える判断と業務から要求を記述する |
| 有名企業名だけで選ぶ | 実担当者と専門領域を確認していない | ケース討議と成果物レビューでチームを評価する |
| 成果保証だけを求める | 市場要因と自社責任を分けられない | 先行KPI、能力条件、双方RACIを合意する |
| 成果物を受け取って終了する | 責任者と更新運用が設計されていない | 共同作成、パイロット、知識移転を契約へ入れる |
SFA刷新案件を、営業モデル改革の選定へ組み替える
以下は、設計の考え方を説明するための架空のモデルシナリオであり、特定企業の事例ではありません。個別の成果や効果を保証するものではありません。
入力率の低いSFAを刷新したい企業を想定します。RFPを機能一覧にせず、重点顧客の選定、案件投資、ステージ判定、予測コミット、マネジャーコーチングという五つの判断を対象にします。候補会社には、現行データの制約を踏まえた診断とパイロット案を求めます。
ケース討議では、同じ案件情報からどの仮説を立て、それを営業プロセス、KPI、画面、データの責任分担としてどのように具体化するかを比較します。採択後もパイロットのGo・No-Goを設け、製品選定は営業モデルとデータ要件が固まった段階で判断します。
着手前の最終チェック
一つでも説明できない項目があれば、ベンダー選定や開発着手の前に仮説と責任を補います。
- 経営課題と営業課題の因果を仮説化している
- 対象顧客・組織・地域・商品と対象外が明確である
- 期待成果物と意思決定ゲートを定義している
- 現場・管理職・IT・データの参加条件がある
- ケース討議で実担当者を評価する
- 知識移転と成果物更新の責任者を決めている
- 特定製品との利益相反を確認する
- パイロットの評価・中止・展開条件がある
よくあるご質問
検討初期に多い疑問を、経営・業務・データ・実行の観点から整理します。
RFP作成前に診断を依頼してもよいですか。
有効です。ただし診断会社がそのまま選定される前提にせず、診断成果物の利用権、事実と仮説、選定時の公平性を整理します。短期診断でRFPの焦点を定める方法もあります。
費用を比較するには何を揃えるべきですか。
体制・役割・期間だけでなく、成果物、現場参加、データ分析、パイロット、知識移転、出張、システム実装の範囲を揃えます。安価でも重要工程がオプションなら総費用は比較できません。
現行ベンダーも候補に含めるべきですか。
選択肢になり得ます。現状への理解は強みですが、既存設計を客観視できるか、実装販売と評価を分離できるか、他案を提示できるかを同じ基準で確認します。
関連する支援とナレッジ
複数テーマが絡む場合も、同じ変革ロードマップ上で優先順位と依存関係を整理します。
営業改革RFPを、支援会社の問題設定力と実装力を見極められる問いへ。
現行RFP、課題メモ、SFA構想をレビューし、対象範囲、評価軸、ケース討議、成果物、知識移転の抜けを整理します。発注前のセカンドオピニオンにも対応します。
営業改革RFPを相談する
コメント