複数拠点の業務を整理し、CRM刷新に向けたRFPを策定

RFPで顧客管理の基本方針を決める

何を標準にし、何を拠点へ委ね、誰が顧客データを持ち、どの変更を許すか。RFPの前半で経営判断を固定し、機能一覧はその後に置きます。

経営が答えるべき問いを先に置く

CRM刷新の前に、顧客をどの単位で認識するか、部門をまたいでどの接点を共有するか、顧客体験と売上・継続・サービス成果をどう結び付けるかを決めます。新しい拠点や商品へ対応できる変更性、機微情報の閲覧制御、顧客データの責任も経営課題です。

RFPの冒頭には、システム導入自体ではなく、利用者と成果を書きます。例えば、担当変更時に過去の約束と未完了タスクを把握できる、拠点横断の重複接触を防ぐ、管理者が案件停滞を早期に検知できる、といった表現です。GOV.UK Technology Code of Practiceも、技術の設計・構築・購入を利用者ニーズから始めるよう求めています。

CRMの価値は入力項目の多さではなく、顧客の状況を部門横断で理解し、次の行動を一貫して選べることにあります。したがってRFPの冒頭には、案件予測の信頼性、引継ぎの連続性、問い合わせ解決、同意管理など、変えたい事業能力を記載します。

• 事業KGI（最終目標を表す指標）と利用者の仕事を対応させる
• 対象顧客・業務・拠点と対象外を明記する
• 導入後の意思決定とデータ利用を定義する

価格差と想定範囲の差を区別する

初期費用だけを並べても、標準機能、設定、追加開発、外部連携のどれで要件を満たすかが違えば比較できません。データ移行、テスト、教育、運用、ライセンス、変更、解約時のデータ返却まで含む複数年TCOを共通内訳で提出させます。

必須条件、望ましい条件、提案事項、参考情報を分け、提案者には前提、除外、依存、制約、リスク、代替案を同じ様式で回答してもらいます。未確定事項を隠すのではなく、何を何のために提案してほしいかを明記することで、価格へ含まれる範囲が透明になります。

提案価格が大きく異なる場合、製品単価ではなく想定範囲が違う可能性があります。データクレンジング、連携改修、拠点展開、教育、移行後支援、追加環境、API（システム連携用の接続口）利用、データ返却を共通の見積構造にし、除外事項と前提条件を回答させます。

• 見積の前提条件と数量を統一する
• 追加費用の単価・条件を確認する
• 終了時の移行支援・削除証明も費用化する

共通化だけを優先せず、六つの対立を整理する

全社と拠点、入力統制と現場速度、可視化とプライバシー、短期導入と変更自由度など、同時に解くべき対立を明示します。

共通化率をKPI（重要業績評価指標）にしない

すべてを共通にすると、法令、契約、顧客特性、業務タイプに必要な差分まで失われます。一方、現行慣習をすべて残すと、データ統合と運用標準化の価値が消えます。差分は、根拠、対象、顧客影響、変更可能性、承認者、有効期限で評価します。

導入時の便利さと、変更時の自由度を比較する

追加開発は現在の操作を再現しやすい反面、製品更新や業務変更のたびに試験と保守が必要です。標準機能への適合は初期の業務変更を伴いますが、継続更新を取り込みやすくなります。RFPでは初期適合だけでなく、三年後に設定や連携を変更するシナリオも評価します。

具体例：顧客と案件が複数拠点をまたぐ場合

以下は特定案件を再現したものではなく、一般的な論点を組み合わせた架空の例です。正常な引継ぎだけでなく、重複、所有競合、同意範囲、担当変更、失注後の再開を含む一連の物語で、提案の実現方式と責任境界を比較します。

シナリオは通常処理だけでなく競合する要求を含める

顧客情報を共有して説明の繰返しを減らしたい一方、機微な相談内容は限定したい。引継ぎを速めたい一方、案件所有権は承認なしに変えたくない。このような対立を含むシナリオで、ロール、フィールド、レコード、監査ログがどう連動するかを確認します。

「対応可能」の内訳を回答させる

同じ対応可能でも、標準、設定、追加開発、外部連携、運用回避では、費用と変更性が異なります。実現方式、前提、制約、更新影響、テスト範囲、運用責任を回答欄として固定し、丸印だけの機能比較を避けます。

拠点差を共通ルール・標準差分・例外に分ける

拠点差をすべて統一も、すべて例外化もしません。法規・顧客価値・業務成果に関わる原則、再利用できる変形、期限付き例外へ分けます。

原則・標準として認める差分・例外へ分ける

主要プロセスごとに、全社で共通にする原則、選択可能な標準として認める差分、拠点固有例外を定義します。法令、契約、顧客特性に基づく差と、慣習や担当者都合による差を区別し、後者は業務改革の候補にします。

例外には根拠、対象、承認者、有効期限を付けます。RFPでは、標準設定で対応する範囲、追加開発が必要な範囲、将来共通化する範囲を提案させます。差分を画面要望の一覧ではなく、共通業務モデルに対する差として表すことで、拠点間の比較と管理が可能になります。

共通原則は、顧客識別、案件状態、活動記録、同意、重要な権限など、全社で意味を揃える項目です。標準として認める差分は業務タイプに応じて設定から選べる差分、承認例外は法令や契約など明確な根拠がある差分です。例外には終了条件を持たせ、永久仕様にしません。

• 顧客登録、活動、案件、引継ぎ、問い合わせを共通モデル化する
• 例外の根拠を法令・顧客価値・業務成果で確認する
• 差分の廃止・見直し時期を決める

代表性のある利用者調査を行う

本部の管理者だけで要件を決めず、役割、業務量、整備段階、顧客特性の異なる拠点を選びます。現場観察、インタビュー、データ分析から、利用者の目標、障害、迂回策、情報利用を把握します。現行画面への不満だけを聞くと、旧システムの制約を新しい要件へ写してしまいます。

利用者ニーズは、誰が、どの状況で、何を達成したいかで記述します。管理者、現場担当、データ管理、サポート、監査など、同じ機能でも異なるニーズを持つ役割を分けます。アクセシビリティやデジタル習熟度も考慮します。

利用者調査では拠点長だけでなく、現場担当、支援部門、管理者、新任者、データ利用者を含めます。繁忙時、引継ぎ、取消、重複顧客、権限変更など例外場面を観察し、「現行画面で困る点」と「顧客・業務結果に必要な点」を分けます。

• 少数の典型担当者だけで全拠点を代表させない
• 実際のデータと帳票の流れを観察する
• 利用者の迂回策を業務課題として記録する

機能・データ・非機能を合格基準で結ぶ

業務例、データ責任、性能・可用性・監査の業務影響を別々に書き、最後に同じシナリオと証拠へ接続します。

機能要件を業務例と合格条件で書く

顧客管理機能や案件管理機能という名称だけでは、実現範囲が分かりません。利用者、開始条件、主要フロー、例外、扱うデータ、完了条件を記述します。例えば、担当者は接触前に、閲覧権限の範囲内で直近の対応と未完了タスクを確認できる、という形です。

各要件について、標準機能、設定、拡張、外部連携のどれで実現するか、制約とアップデート影響を回答させます。受入では、同じシナリオとサンプルデータを使い、操作だけでなく、権限、ログ、通知、例外、データ出力まで確認します。

機能要件は「顧客情報を管理できる」では不十分です。誰が、どの前提で、何を入力・参照・判断し、例外時にどうなり、完了を何で確認するかを記載します。提案評価と受入試験で同じシナリオを再利用すれば、調達時の約束が実装時に消えることを防げます。

• 抽象的な機能名に完了条件を追加する
• 通常処理と主要な例外処理を同じ要件に含める
• 実現方式と将来の保守影響を回答させる

データ要件と性能・安全性などの要件を独立して定義する

顧客識別、重複判定、コード体系、履歴、データ所有者、品質基準、保持・削除、エクスポート、API、文書の属性情報をデータ要件として定義します。顧客、法人、拠点、担当、代理人などの関係を明示し、名寄せの自動判定と人の確認を分けます。

可用性、性能、拡張性、運用、移行、セキュリティは、高ければよいものではありません。業務停止や漏えいの影響から、ピーク時利用、応答、復旧、監査ログ、連携遅延などの測定可能な水準を決めます。IPAの性能・安全性などの要件グレードは、網羅的な項目と段階的合意に活用できます。

データ要件には、顧客識別、重複、正式版、履歴、有効日、同意、保持、削除、品質責任を含めます。性能・安全性などの条件は「高性能」と書かず、繁忙時間の代表操作、許容停止、復旧順序、拠点回線、端末、権限変更の反映時間など、業務影響から段階を選びます。

• オープンな形式とAPIで移行・連携の柔軟性を確保する
• データ品質の所有者と目標を定める
• 性能・安全性などの要件に測定方法と合格条件を付ける

市場調査と同じ業務例で提案を比較する

RFP公開前の候補企業への確認で固定条件と提案事項を磨き、提案者ごとに条件が異なるデモではなく同じデータ・例外・制約で回答を求めます。「対応可能」の内訳を分解します。

固定条件と提案事項をRFP公開前の候補企業への確認で磨く

RFI（情報提供依頼書）では、事業目的、現行の制約、要件案、未確定事項、求める情報を示します。標準機能の制約、実現方式、費用ドライバー、移行の前提、ロードマップを確認し、その結果で要求の過不足を修正します。特定製品の用語へ寄せず、同じ問いを複数の提供者へ投げます。

要件を作るときに、何を証拠に合否と優劣を判断するかも決めます。書面、デモ、技術検証、参照先、チーム面談、見積の評価を組み合わせ、配点だけでなく失格条件を明記します。重大なデータ・セキュリティ条件を価格点で相殺しません。

RFI（情報提供依頼書）では製品一覧を集めるだけでなく、標準機能の境界、データモデル、API制約、リリース方針、運用責任、ライセンス単位、移行支援、終了時の返却方法を確認します。その結果、必須条件として固定すべき事項と、提案に委ねる事項を見直します。

• 未確定項目と提案を求める理由を明記する
• 質問回答を全提案者へ公平に共有する
• 評価基準をRFP公開前に完成させる

提案者ごとに条件が異なるデモではなく同一シナリオで比較する

提案者ごとに条件が異なるデモでは各社が得意な機能だけを見せるため、日常の業務、例外、運用を比較できません。代表的な顧客登録、案件引継ぎ、重複統合、権限付き閲覧、障害時の処理などを共通シナリオにし、同じサンプルデータで実演してもらいます。

画面の華やかさではなく、利用者が完了するまでの操作、標準適合、設定変更のしやすさ、監査ログ、データ抽出、エラー時の回復を評価します。提案書の回答とデモの実装方法が一致するかも確認します。

評価は書面、シナリオデモ、システム構成対話、データ移行試行、運用対話に分けます。重みは事前に決め、重大要件には足切りを設けます。採点者は観察した証拠と懸念を書き、印象点だけで順位を決めません。

• 操作数と利用者の認知負荷を記録する
• 管理者による設定変更も実演させる
• デモで使った前提・未実装部分を記録する

データ移行を提案評価の中心に置く

重複、欠損、履歴、同意、コード体系をサンプルで確認し、移行方式、照合、切戻し、廃止を提案・契約段階から評価します。

サンプルデータで移行可能性を調べる

既存システムごとの顧客ID、重複、欠損、履歴量、添付、個人情報、コード、連携方式を棚卸しします。サンプルでデータ内容と品質の事前調査を行い、移行、クレンジング、アーカイブ、廃棄の対象を分けます。移行後に件数、値、関係、履歴、権限をどう照合するかも定義します。

移行はデータを運ぶだけでなく、旧システムの業務を新しい状態へ切り替える作業です。未完了案件、将来タスク、同意、添付、監査履歴の扱いを決め、切替期間の二重入力や更新競合を避けます。

移行対象を件数だけで把握せず、重複、欠損、コード、関連、履歴、添付、所有者、権限、保持期限を内容と品質の事前調査します。サンプルデータを使い、候補製品のデータモデルへどう対応付けるか、移行後に検索・更新・監査できるかを評価します。

• 移行対象の品質を見積前に数値化する
• クレンジング責任を発注者と受注者で分ける
• 照合基準と許容差、例外承認を決める

代表拠点から学び、標準を更新する

一括導入はリスクを集中させ、段階導入は旧新併存を増やします。拠点の代表性、依存関係、繁忙期、データ品質、切戻し可能性で導入順を決めます。最初の拠点では、単に稼働させるのではなく、業務標準、教育、サポート、KPI、移行手順を検証します。

次の拠点へ進む判断条件には、重要シナリオの受入、データ照合、重大欠陥、運用準備、利用定着を置きます。学習によって共通標準を更新し、差分を増やすのではなく再利用可能な設定と教育資産を増やします。

代表拠点の限定導入では、標準を一方的に押し付けず、例外発生とシステム外管理を観察します。そこで見つかった事実を、設定、業務標準、教育、データ品質ルールへ戻してから次拠点へ展開します。拠点数ではなく、学習が標準へ反映されたことを判定段階にします。

• パイロット拠点を容易さだけで選ばない
• 展開判断をKPIと重大リスクで定義する
• 知識移転と内製運用能力を契約へ含める

RFP・評価表・契約・導入判断をつなげる

提案時の約束が、評価、契約、PoC、代表拠点、展開判定まで追跡できるようにします。固定条件と検証後に見直せる条件を分けます。

固定条件と検証後に見直せる条件を分ける

法令、データ所有権、セキュリティ、必須連携、終了時返却などは固定します。一方、画面配置、詳細ワークフロー、拠点展開順序などは、代表利用者との検証で更新できる条件にします。変更手続、費用算定、優先順位、受入基準を契約へ反映します。

三つの段階で段階投資する

段階1は要求と市場で実現可能か、段階2は代表シナリオとサンプルデータ、段階3は限定拠点の利用・品質・運用です。各段階で継続、条件付き継続、再設計、中止を判断し、全額投資を一度に後戻りできない投資にしません。

詳細なRFPでも比較できない兆候を確認する

前提の違う価格、標準と追加開発の混在、データ責任の空白、出口不明、例外の無制限化が見えたら、選定を急がず要求の整理方法へ戻ります。

調達中に見る早期兆候

質問が価格と期日へ偏る、前提差が解消しない、提案条件が異なるデモだけで優劣が決まる、といった兆候には注意が必要です。実現方法やデータ返却が曖昧な場合も、評価を止めて条件を整理し直します。質問数の少なさは明確さではなく、対話不足の可能性があります。

導入後に見る見直し判断兆候

外部表計算が増える、拠点例外が恒久化する、顧客重複が解消しない、変更のたびに追加開発が必要、利用者が入力を避ける場合は、製品ではなく共通化原則や責任設計を再検討します。

将来の変更と契約終了まで評価する

初期機能だけでなく、設定変更、データ持出し、監査、引継ぎ、終了支援を評価します。選ぶのは一時点の製品ではなく、顧客運営を更新し続ける条件です。

将来変更と特定の提供会社から移りにくい状態を評価する

設定変更の権限、開発・テスト・本番の分離、リリース頻度、自動テスト、障害対応、サポート時間、製品更新への追随を確認します。GOV.UKの技術選定ガイダンスは、理解が変わったときに技術を適応させ、後で判断を変えられることを重視します。

契約終了時には、データと文書の属性情報の返却形式、API、添付、履歴、設定、ログ、削除証明、移行支援を定義します。オープン標準を利用し、特定提供者だけが読める形式や、抽出に過大な費用がかかる条件を避けます。

DXwheelは、事業成果、利用者調査、共通業務と拠点差の一覧、データ・性能・安全性などの条件、RFI（情報提供依頼書）、RFP、評価シナリオ、移行・運用・出口条件を一貫させます。

• 設定と追加開発の所有・利用権を確認する
• データ抽出を契約前に試験する
• サービス終了・重大障害時の移行支援を定める

DXwheelが支援できる領域

DXwheelは製品選定の前に、利用者、共通業務、拠点差、データ状態、性能・安全性などの要件を整理します。さらに、情報提供依頼、見積様式、評価用の業務例、デモ手順、段階導入計画を作ります。提案者と利害が分離された立場で、要求の過不足、前提差、カスタマイズ依存、移行・出口リスクを可視化します。

実際のRFPでは、組織の意思決定、現行データ、契約条件、市場状況を確認し、公平性と比較可能性を満たす手続を設計します。

• 事業・現場・データ・調達を一つの要求の整理方法へ統合する
• 共通シナリオで提案の実現性を比較する
• 段階導入と出口まで含む意思決定材料を作る