施策名ではなく、経営判断の詰まりから始める
従来のRFPは数百の機能要件へ○△×を付ける形式になりがちです。しかし各社の○は標準、設定、追加開発、外部製品で意味が異なります。営業現場がどの状況で何を判断し、その後どの行動を取るかが見えないため、デモは見栄えの良い画面紹介になり、稼働後に業務不一致が判明します。
RFPでは、代表ユースケース、利用者、データ、量・鮮度、権限、例外、業務SLA、連携、移行、運用、定着を提示します。候補ベンダーには標準適合、業務変更、拡張、代替案、前提、制約、将来アップデートへの影響を回答してもらい、ライフサイクル全体で比較します。
経営課題
入力負荷の削減だけでなく、重点顧客・案件・予測・支援配分の判断を改善する。
変える判断
営業、管理職、営業企画、マーケ、サービスが同じ顧客・案件状態を使う。
実装単位
シナリオデモと代表データでFit・移行・連携・権限を検証する。
確認する証拠
標準適合、利用、データ品質、変更容易性、TCOで製品と実装を評価する。
構想・投資を決める4つの判断基準
個別施策や解決策を検討する前に、経営・業務・データ・実行の整合を確認します。4つの観点が同じ仮説につながって初めて、実行可能な構想になります。
| 判断軸 | 経営が問うこと | 合格状態 | 見逃した場合のリスク |
|---|---|---|---|
| 業務適合 | 重要ユースケースを自然に実行できるか | 代表シナリオを自社データ・役割・例外でデモする | 機能はあるが現場操作と管理判断が分断する |
| 標準性 | 設定・拡張・開発・業務変更を区別したか | 差分とアップデート影響を項目別に示す | 初期費用と保守負債を過小評価する |
| データ・連携 | 顧客・案件の正本と境界が明確か | 正本システム、ID、同期、エラー、履歴を定義する | CRMが別のデータ島になる |
| 運営・TCO | 稼働後の変更と定着を維持できるか | 管理者能力、リリース、サポート、ライセンス、拡張費を比較する | 導入後の改善が止まる |
判断原則：RFPの要求はMustを絞り、Should・Couldと業務変更可能性を分けます。例外をすべて再現せず、標準へ寄せる判断と、競争優位のために残す差異を経営が選びます。
実務で分解すべき設計論点
「あるべき姿」を標語で終わらせず、会議、業務、役割、情報、データ、システム、移行の選択肢へ分解します。
ユースケースを意思決定シナリオで書く
利用者、トリガー、必要情報、判断、操作、例外、完了条件、下流連携を一続きで記述します。項目名だけでなく、会議や顧客対応でどう使うかを候補企業に示します。
シナリオデモを統制する
全社へ同じ台本、代表データ、時間、回答様式を渡し、標準・設定・拡張をその場で明示させます。録画や判断ログを残し、印象ではなく評価軸で採点します。
データ移行を別工程にしない
顧客名寄せ、案件履歴、活動、添付、同意、所有者、休眠データ、品質基準を選定中に確認します。移行不可能なデータが業務要件へ与える影響も評価します。
TCOを変更量でシナリオ化する
ライセンスだけでなく、実装、連携、データ、テスト、教育、管理者、追加開発、アップデート、環境、廃止を含めます。利用者・データ量・変更頻度の複数シナリオで比較します。
構想から定着までの5ステップ
各段階に意思決定ゲートを置き、資料を作った量ではなく、次へ進める根拠が揃ったかで進捗を判定します。
営業判断と対象範囲を定義する
変える営業・顧客判断、利用者、地域、商品、チャネル、現行課題、対象外を整理します。現行画面の置換ではなく将来業務の仮説を作ります。
製品に依存しない業務目的が明確
要求とデータ条件を構造化する
ユースケース、Must・Should・Could、データ、連携、権限、性能、監査、移行、運用、定着を記述します。回答形式と前提開示を統一します。
標準・設定・拡張を比較できる
RFI・デモで候補を絞る
市場情報と適合仮説で候補を絞り、シナリオデモと質疑で検証します。製品と実装パートナーを分けて評価する場合は責任境界も確認します。
重要ギャップと代替案が可視化された
代表データでリスクを検証する
高リスク領域だけPoCまたは技術検証を行います。目的、合格条件、廃棄・再利用方針を決め、デモ開発そのものを本番設計にしません。
重大な技術・業務・移行リスクを判断できる
契約・実装・受入へ接続する
選定理由、Fit・Gap、前提、未決、データ責任、変更、受入、定着を契約とバックログへ引き継ぎます。選定チームから実装チームへの知識断絶を防ぎます。
RFPの判断が実装統制へ残っている
検討初期から、業務責任者、経営企画、IT・データ担当、現場代表が同じ議論に参加します。論点ごとの決定者と協議者を明確にし、未決事項は課題管理表で追跡します。全社を一度に詳細化せず、価値と依存関係の大きい領域に対象を絞り、業務からデータ・システムまで一連の流れを検証して仮説を更新します。
戦略・業務・データ・システム・移行を切らない
エンタープライズアーキテクチャの使いどころ
CRMを単独製品として見ず、MA、ERP、見積、契約、サービス、DWHとのアプリケーションポートフォリオ上の責任を定義します。ビジネスアーキテクチャの営業・顧客能力からユースケースを作り、移行アーキテクチャで段階移行と旧システム廃止を設計します。
DAMA-DMBOKの使いどころ
顧客、個人、アカウント階層、案件、活動、商品、同意の定義とデータ責任者を決め、データ品質、参照・マスタ、統合、セキュリティ、メタデータの要求として具体化します。個人情報や自由記述を分析イベントへ送らないなど、利用目的と最小化も選定条件にします。
EAとDMBOKは、成果物を増やすための形式ではありません。今回の意思決定に必要な範囲に絞って適用し、現行・目標・移行状態の差、データの意味と責任、変更の影響を説明できるように使います。フレームワーク名を掲げるだけでなく、責任者、承認権限、更新頻度、品質基準まで定めて初めて運用できます。
会議で決め、現場が使える成果物
成果物は分量の多い完成版文書ではなく、判断の前提、選択肢、責任、移行条件を追跡し、継続的に更新できる設計資産として作ります。
SFA・CRM RFP
目的、範囲、シナリオ、要求、データ、連携、移行、非機能、運用、定着を構造化します。
使いどころ：候補企業に同一の前提を提示する
シナリオデモ台本
役割、代表データ、操作、例外、評価観点、標準・拡張区分を定義します。
使いどころ：営業現場とITが同じ基準で評価する
Fit・Gap・判断ログ
標準適合、業務変更、設定、拡張、代替、前提、決定者を残します。
使いどころ：選定根拠と実装スコープを追跡する
TCO・リスク比較モデル
ライセンス、実装、データ、連携、運用、変更、廃止を複数シナリオで比較します。
使いどころ：初期費用ではなくライフサイクルで選ぶ
よくある失敗と、早期の是正方法
失敗の多くはツールの機能不足ではなく、目的、対象範囲、責任、データ、移行条件の曖昧さから起きます。
| 失敗パターン | 構造的な原因 | 是正する方法 |
|---|---|---|
| 全要望をMustにする | 優先度と業務変更可能性がない | Mustを判断・法令・重大リスクへ絞る |
| ○△×表だけで選ぶ | 実現方法と前提が比較できない | シナリオデモとFit・Gap区分を使う |
| 移行を採択後に検討する | 品質・履歴・同意の制約を見ていない | 代表データのプロファイルを選定中に行う |
| 価格交渉で体制を削る | データ・定着・変更管理が対象外になる | 成果物と責任を揃えてTCOを比較する |
機能の採点表の製品選定を、営業シナリオのFit評価へ変える
以下は、設計の考え方を説明するための架空のモデルシナリオであり、特定企業の事例ではありません。個別の成果や効果を保証するものではありません。
多数の要望をRFPへ集めた企業を想定します。要望を分析すると、実際に重要なのは顧客優先度、案件ステージ、支援依頼、予測コミットの四つの意思決定でした。これらを役割・データ・例外付きのシナリオへ変え、候補製品に同じ台本でデモを求めます。
各機能の有無ではなく、標準、設定、拡張、業務変更、外部連携を記録します。高リスクなアカウント階層と権限制御だけ代表データで検証し、TCOと将来変更を含めて採択します。
着手前の最終チェック
一つでも説明できない項目があれば、ベンダー選定や開発着手の前に仮説と責任を補います。
- 変える営業判断と顧客体験を定義している
- 代表ユースケースに役割・データ・例外・完了条件がある
- Must・Should・Couldと対象外を分けている
- 標準・設定・拡張・業務変更を区別して回答させる
- 移行対象とデータ品質を選定中に確認する
- 同じシナリオデモ台本で比較する
- 運用・変更・教育・管理者をTCOに含める
- 選定判断を実装バックログと受入へ引き継ぐ
よくあるご質問
検討初期に多い疑問を、経営・業務・データ・実行の観点から整理します。
RFP前に製品を絞ってもよいですか。
市場・技術・既存契約から候補を絞ることはあります。ただし製品都合で業務目的を変えないよう、製品に依存しない重要シナリオと評価軸を先に定義します。
PoCは必ず必要ですか。
必須ではありません。標準デモと参照情報で判断できる領域にPoCは不要です。複雑な権限、大規模データ、連携、オフラインなど重大な不確実性だけを合格条件付きで検証します。
製品と実装パートナーを同時に選ぶべきですか。
一括選定と分離選定の双方があります。責任一元化、専門性、競争性、移行知識を比較し、製品適合性と実装能力を別軸で採点します。
関連する支援とナレッジ
複数テーマが絡む場合も、同じ変革ロードマップ上で優先順位と依存関係を整理します。
機能一覧を、選定後も使える意思決定仕様へ。
RFP、要件一覧、提案書、デモ台本をレビューし、営業シナリオ、データ、移行、TCO、Fit・Gap、受入条件の抜けを整理します。
SFA・CRM選定を相談する
コメント