SFA・CRMが老朽化し、入力されない、改修に時間がかかる、周辺システムとの連携が複雑という課題が重なると、製品を入れ替えれば解決すると考えがちです。しかし、現行の営業プロセス、不要な項目、重複データ、個別カスタマイズをそのまま新環境へ移せば、使いにくさと技術負債も再現されます。一方、全社を一度に切り替えると、商談・顧客履歴の欠落や営業活動停止の影響が広がります。
製品入替を目的にせず、負債を評価し、目標像を定め、段階移行と旧環境廃止までを管理します。
安全なリプレイスは、刷新目的と対象能力を定め、現行・目標・移行期のアーキテクチャを描き、業務単位または組織単位のウェーブで移行する取り組みです。本記事では、停止リスクを抑えながら価値を段階的に実現するロードマップを解説します。
この記事でわかること
- SFA・CRMの刷新が必要かを診断する観点
- 目標アーキテクチャと移行期アーキテクチャの作り方
- パイロット、段階展開、並行稼働の選び方
- データ移行、切替判定、ロールバック、旧環境廃止の条件
刷新目的を製品サポート期限だけにしない
サポート期限や契約更新は重要な期限ですが、それだけでは投資の優先順位と設計判断を導けません。営業組織改革として、案件創出、提案、予測、引き継ぎ、顧客理解のどの能力を変えるかを定めます。成果指標はシステム稼働ではなく、営業活動のリードタイム、データ鮮度、予測の説明可能性、二重報告の廃止などで設定します。
| 刷新シグナル | 確認する事実 | 判断の方向 |
|---|---|---|
| 現場が利用しない | 役割別利用、二重入力、会議での利用、現場にとっての利点 | プロセス・定着を含む再設計 |
| 改修が遅い | カスタマイズ、依存、テスト範囲、リリース頻度 | 標準化・疎結合化・ALM改善 |
| 数字が合わない | KPI定義、顧客重複、履歴、連携遅延 | データガバナンスと品質改善 |
| 連携障害が多い | 点対点接続、再送、監視、責任分界 | 連携アーキテクチャ刷新 |
| コストが上昇 | ライセンス、運用、個別開発、周辺ツール | 総保有コストと業務価値で比較 |
| 製品・基盤の制約 | 保守期限、セキュリティ、性能、拡張性 | 期限付き移行とリスク対策 |
診断結果から、維持、改善、部分刷新、全面刷新、廃止を機能単位で判断します。使われていない機能まで移行対象にせず、「新環境で作らないもの」を明示することがスコープ管理に有効です。
現行・目標・移行期の三つを描く
現行調査では、画面と機能だけでなく、営業プロセス、組織差、レポート、権限、データ量・品質、API、バッチ、ファイル、運用手順、契約、担当者依存を棚卸しします。アクセスログと連携ログで実態を確認し、各資産に責任者、利用部門、重要度、停止影響、変更頻度、廃止可否を付けます。
目標アーキテクチャでは、営業能力、標準プロセス、データ責任、アプリケーション機能配置、連携、技術・運用標準を定義します。SFA・CRM要件定義では、現行機能の再現ではなく、将来の意思決定と営業行動から要件を導きます。
移行期アーキテクチャは、新旧併存中だけ必要な構成です。どちらで顧客・商談を更新するか、データをどう同期するか、共通IDをどう扱うか、レポートの参照先をいつ変えるか、障害時にどちらを正とするかを期間とともに定めます。移行期を設計しない段階展開は、二重更新とデータ不一致を生みます。
| 設計対象 | 現行で確認 | 目標で決定 | 移行期で管理 |
|---|---|---|---|
| 営業プロセス | 部門差・例外・旧報告 | 標準と許容する差 | 新旧手順と教育対象 |
| データ | 重複・欠損・履歴・責任 | 正データ、品質、保持 | 同期方向、新旧ID、照合 |
| アプリ機能 | 利用実績・個別開発 | 標準、拡張、廃止 | 機能別切替と代替 |
| 連携 | 方向、頻度、障害、責任 | API・イベント・バッチ | 一時的なインターフェース、切替順、監視 |
| 運用 | 変更、権限、サポート | プロダクト運営とALM | 二重運用、重点支援 |
段階移行ロードマップ
| フェーズ | 主な活動 | 次へ進む条件 |
|---|---|---|
| 0. 構想・統制 | 目的、成果指標、スポンサー、意思決定、全体スコープ | 業務・IT・データ責任者が承認 |
| 1. 診断・棚卸し | 能力、プロセス、データ、連携、運用、コストを可視化 | 依存と廃止候補を把握 |
| 2. 目標・移行設計 | 標準プロセス、データモデル、アーキテクチャ、ウェーブ | 原則と受入基準を合意 |
| 3. 基盤・パイロット | 環境、権限、連携、移行、教育を代表チームで一巡 | 品質・利用・運用の実測が基準内 |
| 4. ウェーブ展開 | 組織または業務能力単位で移行し、学びを反映 | 各ウェーブのGo／No-Goを通過 |
| 5. 安定化・廃止 | 重点監視、問題解決、旧IF・報告・環境の停止 | 保持・監査・復元要件と廃止承認 |
パイロットは簡単な部門だけでなく、代表的な営業プロセス、データ、連携、権限を含み、失敗しても影響が限定される対象を選びます。営業プロセス標準化、営業KPI、パイプライン・予実管理まで一巡させることで、後続の実行時間と支援負荷を実測できます。
展開方式を業務リスクで選ぶ
| 方式 | 適する状況 | 利点 | 注意点 |
|---|---|---|---|
| 一括切替 | 組織・機能が小さく、短期併存が難しい | 二重運用を短くできる | 失敗時の影響が広く、切り戻しが難しい |
| 組織別段階展開 | 地域・事業部ごとに利用を分離できる | 先行部門から学べる | 部門をまたぐ商談と共通顧客を管理 |
| 機能別段階展開 | リード、商談、サービス等を分離できる | 価値を早く出しやすい | 新旧間の一時連携が複雑 |
| 並行稼働 | 新旧結果の照合が必要で、許容停止時間が短い | 出力比較と切り戻し先を確保 | 終了条件がないと二重入力が恒常化 |
MicrosoftのDynamics 365実装ガイダンスは、展開戦略を事業目的、リスク許容度、予算、資源、時間に合わせ、パイロット、段階展開、並行稼働などを検討する考え方を示しています。特定ベンダーにかかわらず、対象業務の分離可能性と停止影響から方式を選びます。
データ移行と連携切替を別計画にしない
CRMデータ移行では、顧客名寄せ、商談・活動履歴、同意、新旧IDを品質保証します。同時にCRM・MA・ERP・DWH連携の切替順序、最終同期、未処理メッセージ、レポート参照先をカットオーバー計画へ統合します。新CRMだけが動いても、価格、受注、顧客、分析がつながらなければ営業は再開できません。
Go／No-Go判定の主要ゲート
| ゲート | 判定基準 | 責任者 |
|---|---|---|
| 業務 | 主要シナリオのUAT完了、重大課題ゼロ | 営業プロセス責任者 |
| データ | 重要項目、件数、関係、履歴、権限が基準内 | データ責任者 |
| 連携 | 送受信、再送、照合、停止時の代替手段を確認 | アプリ・連携責任者 |
| 性能・運用 | ピーク性能、監視、バックアップ、復旧訓練完了 | サービス責任者 |
| 人・支援 | 対象者教育、権限、問い合わせ・重点支援を準備 | チェンジ責任者 |
| 切り戻し | トリガー、決定者、手順、所要時間、切り戻し時に新システム側の更新データを失わないための方法 | リリース責任者 |
本番と同じ順序・人員・時間枠で模擬切替を行い、各作業の開始・終了、依存、証跡、失敗時の分岐を更新します。Salesforceは本番と分離したサンドボックスで開発・テスト・教育を行う考え方を、Microsoftは本番前にシステム統合、UAT、性能、データ移行、カットオーバー、教育、権限の準備を確認する考え方を公式に示しています。
チェンジマネジメントをシステム開発と並行して進める
新画面の研修を稼働直前に行うだけでは不十分です。影響を受ける役割、変わる業務、廃止する旧報告、管理職の会議運営、評価、支援体制を構想段階から計画します。SFA定着のチェンジマネジメントとして、代表利用者との共同設計、部門チャンピオン、役割別訓練、稼働後のフィードバックをウェーブごとに実施します。
顧客360度ビューの品質や権限も現場の信頼を左右します。新環境で何が便利になるかだけでなく、誰の仕事が増減し、何をしなくてよくなるかを具体的に伝えます。
EAとDMBOKで刷新を全社最適へつなげる
EAでは、営業能力、業務、データ、アプリケーション、技術を現行・目標・移行期で追跡し、各ウェーブがどの事業成果を実現するかをロードマップ化します。The Open GroupのTOGAF Standardは、標準化された方法とコミュニケーションを支え、製品選定に偏らず移行全体を統制する枠組みとして活用できます。
DAMA-DMBOKでは、顧客・商談データを移行対象物ではなく継続管理する資産として扱います。ガバナンス、マスタ、品質、メタデータ、統合、セキュリティの役割・ルールを新しい運用へ引き継ぎます。刷新後に重複や定義不一致を再発させないため、データ品質指標と問題管理をプロダクト運営へ組み込みます。
実務チェックリスト
- 刷新目的と事業成果を製品更改以外の言葉で定義した
- 現行の業務・データ・連携・運用・契約を証拠ベースで棚卸しした
- 維持・改善・刷新・廃止を機能単位で判断した
- 目標と移行期のアーキテクチャ、原則、責任を合意した
- 代表性があり影響を限定できるパイロットを選んだ
- 組織別・機能別・一括・並行を業務リスクで選定した
- データ移行と連携切替を一つのカットオーバー計画にした
- Go／No-Go基準と最終決定者を事前に定めた
- ロールバックを非本番で実行し、所要時間を確認した
- 旧報告、旧連携、旧環境の廃止条件と責任者が明確である
まとめ
SFA・CRMリプレイスは、旧機能を新製品へ写すプロジェクトではありません。営業能力、データ、連携、運用、現場行動を目標像へ段階的に移す変革です。移行期アーキテクチャとウェーブごとの受入・切り戻し条件を設計し、小さな成功と実測を次へ反映することで、停止リスクと手戻りを抑えられます。
高度設計：機能単位で刷新方針と出口を決める
SFA・CRM刷新では、製品を一括で置き換える前に、顧客管理、活動、商談、見積、予測、承認、レポートなどの能力ごとに、維持、再設定、置換、再構築、廃止を決めます。判断材料は機能差だけでなく、事業価値、規制、変更頻度、データ品質、連携依存、運用費、将来の移行・廃止の難しさです。EAでは目標像に加えて各ウェーブ後の移行期状態を描き、DMBOKでは正データ、品質責任、メタデータ、保持・廃棄を旧新双方へ割り当てます。
| 方針 | 適する状態 | 必要な証拠 | 出口条件 |
|---|---|---|---|
| 維持 | 差別化せず安定、変更が少ない | 費用、障害、契約、依存 | 連携と責任を継続監視 |
| 再設定 | 標準機能で業務を簡素化できる | Fit-to-standard、例外量 | 旧カスタムを停止 |
| 置換 | 保守性・統制に構造課題 | 業務シナリオ、非機能試験 | 新システムで成果と統制を再現 |
| 再構築 | 競争優位の独自能力 | 価値仮説、所有権、技能 | 継続投資の責任者を任命 |
| 廃止 | 利用・価値がない重複機能 | 利用ログ、法定保持、依存 | 証跡保管とアクセス撤去 |
標準業務、正データ、権限、連携、SLOとプロダクト責任を定義します。
旧新の更新権限、同期方向、差分照合、暫定手作業と期限を明記します。
旧ID参照、帳票、連携、契約、アカウント、データを閉鎖する証跡を残します。
移行台帳は、能力、旧機能、新機能、旧ID、新ID、変換ルール版、最終同期時刻、更新権限、未解決例外、受入責任者、廃止日を一件で追える形にします。並行稼働中に両方を更新可能にすると競合が増えるため、属性・プロセスごとに片側だけを書込み元とし、反映遅延と訂正経路を利用者へ明示します。
非機能・統制をGo／No-Goの数値条件にする
| 観点 | 判定指標の例 | 統制・回復策 |
|---|---|---|
| 可用性 | 業務時間SLO、重大障害件数 | 縮退運転、連絡網、手作業代替 |
| 性能・容量 | p95応答、ピーク処理量、バッチ完了 | 負荷試験、上限監視、容量余力 |
| 復旧 | RTO、RPO、再送・再移行時間 | バックアップ、ロールバック演習 |
| データ | 件数、金額、参照整合、重複率 | 統制合計、例外台帳、業務承認 |
| セキュリティ | 重大権限違反、監査証跡欠損 | 最小権限、職務分離、認証情報・秘密鍵の更新 |
カットオーバー計画には、タスク順、所要時間、主担当・代替担当、入力、実行証跡、検証、承認、ロールバック判断期限を持たせます。本番相当データ量で複数回リハーサルし、最終回は同じ担当者、ツール、順序で実施します。凍結開始から新環境の業務確認までを一本のタイムラインで測り、見込みでなく実測時間を計画へ反映します。
ハイパーケアと旧環境廃止を先に設計する
稼働直後は問い合わせ件数だけでなく、重要業務の完了率、入力滞留、同期遅延、予測差異、手動補正時間を日次で確認します。指揮系統を一本化し、重大度、業務回避策、修正責任、次回更新時刻をチケットと状況報告で一致させます。安定判定は一定期間のSLO達成、重大欠陥ゼロ、運用引継ぎ完了、現場責任者の承認を組み合わせます。
旧環境を止める前に、法定・契約上の保持、監査検索、係争時の抽出、参照権限を確認します。読取り専用化、アーカイブ検証、アカウント・秘密情報の失効、DNS・ジョブ・APIの停止、ライセンス解約を順に実行し、依存先からの通信が消えた証跡まで保存します。撤去を別案件へ先送りせず、刷新ウェーブの完了条件に含めることが二重運用費の抑止になります。
| 意思決定 | A：最終責任 | R：実行責任 | C：協議 |
|---|---|---|---|
| 業務受入・Go判断 | 業務スポンサー | プロセス責任者 | 品質、IT、現場代表 |
| データ移行承認 | データ責任者 | 移行責任者／データ管理担当者（データスチュワード） | 監査、利用部門 |
| 技術切替・復旧 | サービス責任者 | リリース責任者 | 連携、基盤、セキュリティ |
| 旧環境廃止 | 事業責任者 | 資産・契約管理 | 法務、データ、利用部門 |
刷新能力の成熟度モデル
| 段階 | 状態 | 次の到達条件 |
|---|---|---|
| 1 更改中心 | 期限と機能移植が中心 | 能力・価値・依存関係の可視化 |
| 2 計画統制 | 移行、試験、切替の標準がある | 移行期状態と退出条件を承認 |
| 3 段階最適 | 実測により後続ウェーブを改善 | プロダクトKPIと技術負債を統合 |
| 4 継続刷新 | 小規模なリリースと廃止を継続的に実施する | 価値・リスクで投資を再配分 |
ウェーブ別成果物とレビューゲート
| 段階 | 必須成果物 | 終了条件 |
|---|---|---|
| 0 ベースライン | 能力台帳、現行EA、データ品質、依存図 | 範囲・除外・評価基準を承認 |
| 1 基盤 | 目標／移行期EA、原則、ID・権限設計 | 非機能要件と責任分界を試験可能な条件で定義する |
| 2 パイロット | 移行台帳、教育、運用手順、切り戻し条件 | 代表業務で成果と復旧を実証 |
| 3 展開 | ウェーブ計画、Go基準、切替ランブック | 各波で照合・受入・改善を完了 |
| 4 退出 | 廃止完了の証跡、保持台帳、契約終了、振り返り | 旧アクセス・連携・費用を閉鎖 |
用語解説
- Fit-to-standard
- 製品標準へ業務を合わせ、例外だけを根拠付きで追加する設計方法。
- 移行期アーキテクチャ
- 目標到達までの一時的な業務・データ・システム・責任の状態。
- RTO／RPO
- 復旧までの目標時間と、障害時に許容するデータ損失時点。
- 廃止完了の証跡
- データ保持、依存解除、権限撤去、契約終了を確認した承認記録。
設計の参考にした公式資料
SFA・CRM刷新を構想から定着まで伴走します
Version株式会社では、EAとDMBOKをベースに、現状診断、目標・移行期アーキテクチャ、製品中立の要件、データ移行、連携、定着を一貫して支援します。
参考資料
- Salesforce Help「When to Use a Sandbox」
- Salesforce Help「Plan and Prepare for Deployment」
- Microsoft Learn「Plan an implementation strategy」
- Microsoft Learn「Prepare your production environment to go live」
- The Open Group「TOGAF Standards」
- DAMA International「What is Data Management?」
営業改革・SFA・CRMテーマクラスター：営業組織改革の全体像 ／ SFA・CRM要件定義 ／ 営業プロセス標準化 ／ 営業KPI設計 ／ パイプライン・売上予測 ／ 顧客360・マスタデータ ／ SFA定着 ／ CRMデータ移行 ／ CRM・MA・ERP・DWH連携 ／ SFA・CRM刷新
関連するBI／DWHナレッジ：意思決定から逆算するBI要件定義 ／ セマンティックレイヤー ／ データ不一致とリネージュ
コメント