SFA / CRM
SFA・CRM・Salesforce導入支援
営業・マーケティング・サービスの業務設計、顧客データ、Salesforceアーキテクチャ、定着運営を一体で構築します。
- 01顧客を識別Account・Contact・Consent
- 02案件を判断Stage・Exit Criteria・Next Action
- 03活動を改善接点・引継ぎ・自動化
- 04予測を更新Forecast・Bias・介入
- 05学習を戻す勝敗・利用・品質・変更
次の判断利用率ではなく、商談判断、予測、顧客対応が改善し、その結果として入力が続くかを測ります。
DXwheel設計フレームワークによる概念図。個別案件では現状証跡と制約に合わせて更新します。
適用条件と着手判断
この支援が有効な状況、最初に決める事項、適用境界を明示します。製品・手法の採用自体を目的にはしません。
入力されない・更新されない
利用者の行動、管理判断、顧客価値と入力項目が接続していない
予測精度が上がらない
ステージ定義、Exit Criteria、金額、確度、期日、失注理由が曖昧
顧客データが重複
Account、Contact、Lead、Party、Consentの識別・統合責任が不明
カスタマイズが増殖
業務ルールと権限が自動化・コード・外部連携へ分散
ご相談が多い状態
現場が入力しない
入力が本人の行動改善や案件支援につながらず、管理報告だけに使われる。
案件定義が曖昧
ステージ、確度、次アクション、失注理由が部門・担当者で異なる。
顧客が重複
取引先、拠点、担当者、契約、商談の識別・名寄せ責任がない。
改修が止まらない
要求の価値、標準代替、保守影響、廃止条件を審査していない。
診断で確認する証跡
ヒアリングだけに依存せず、文書、設定、ログ、利用実績、品質結果、契約、運用記録を突き合わせます。未確認と推定は事実と分けます。
- 01
顧客ライフサイクル
Lead-to-Order、Onboarding、Service、RenewalのBPMNとKPI
- 02
データモデル
顧客、担当者、商談、活動、商品、契約、同意、ケース
- 03
利用実態
ログイン、更新、活動、レポート、モバイル、API、エラー
- 04
自動化・拡張
Flow、Apex、Validation、権限、パッケージ、技術負債
- 05
連携
MA、ERP、EC、CTI、DWH、ID管理、マスタ同期
- 06
運用
リリース、Sandbox、テスト、監視、教育、問い合わせ、バックログ
支援ワークストリーム
営業・サービスプロセス
リードから受注、継続、問い合わせ対応までをBPMNと判断ルールで定義します。
顧客・案件データ
顧客360の目的、マスタ、重複、履歴、権限、品質を設計します。
Salesforce設計
標準機能、設定、Flow、コード、連携、データ量、セキュリティを評価します。
定着・改善運営
ロール別価値、教育、利用支援、バックログ、リリース、KPIを運用します。
主要な設計判断
各判断は、目的、制約、選択肢、評価軸、採用・棄却理由、決定者、見直し条件をArchitecture Decision Recordとして残します。
顧客識別
CRM主、MDM主、ERP主、連邦型
顧客類型、契約、同意、重複、更新源、リアルタイム性
プロセス標準
全社共通、事業テンプレート、事業固有
営業モデル、商品、規制、顧客接点、管理KPI
自動化方式
標準設定、Flow、Apex、外部オーケストレーション
複雑性、量、同期性、保守者、テスト、限界
共有・権限
役割階層、共有ルール、チーム、テリトリ、手動共有
最小権限、協働、性能、運用、監査
統合
API、Platform Event、CDC、バッチ、MuleSoft等
遅延、整合性、順序、再処理、限界、費用
定着
強制入力、誘導、既定値、自動取得、廃止
判断価値、入力負荷、品質、監査、利用者体験
主要成果物と利用者
| 成果物 | 意思決定・利用目的 | 主な責任者 |
|---|---|---|
| 営業・サービスBPMN | 役割、判断、例外、引継ぎ、SLAを可視化 | 営業/サービス責任者 |
| ステージ・判断基準 | 案件進捗、必須情報、次アクションを標準化 | 営業企画 |
| 顧客・案件論理モデル | 取引先、拠点、担当者、商談、契約の関係を定義 | データオーナー |
| Salesforce設計原則 | 標準、Flow、コード、連携、権限、データ量の判断基準 | アーキテクト |
| 定着シナリオ | ロール別価値、教育、支援、現場フィードバックを計画 | 変革責任者 |
| 運用・リリース設計 | 要求受付、優先度、テスト、権限、監視、廃止を統制 | プロダクトオーナー |
進め方と品質ゲート
EA・業務・データ・システムの対応
同じ設計対象をBusiness、Data、Application、Technologyへ分断せず、責任とKPIまで縦に追跡します。
Business
営業・サービス・承認BPMN
- GOVERNANCE
- ステージ、SLA、ロール
- KPI FOCUS
- 生産性・転換・継続
Data
顧客・案件・活動・契約
- GOVERNANCE
- マスタ、品質、共有、保持
- KPI FOCUS
- 重複・完全性・鮮度
Application
Salesforce機能・拡張・連携
- GOVERNANCE
- Trusted/Easy/Adaptable
- KPI FOCUS
- 保守性・利用・障害
Technology
認証・監視・環境・ALM
- GOVERNANCE
- セキュリティ、性能、継続性
- KPI FOCUS
- 可用性・変更成功
責任分界と運営
会議体の設置ではなく、誰が何を決定し、どの証跡を確認し、例外をいつ再評価するかを日常業務へ組み込みます。
ビジネスオーナー
売上・サービス成果、プロセス、KPI、優先順位
プロダクトオーナー
ロードマップ、バックログ、受入、利用、廃止
データオーナー
顧客定義、品質、共有、同意、重複処理
プラットフォームアーキテクト
Trusted・Easy・Adaptable、拡張、統合、非機能
CRM CoE/管理者
設定、リリース、監視、教育、問い合わせ、標準
KPIと測定定義
数値目標は基準値と業務影響を確認して合意します。測定式、データ源、頻度、責任者を固定し、単一指標による局所最適を避けます。
| 指標 | 定義・算定上の注意 | データ源 | 頻度 | 責任者 |
|---|---|---|---|---|
| ステージ健全性 | Exit Criteriaを満たし、金額・期日・次行動・意思決定者が期限内更新された商談割合 | 商談・活動 | 週次 | 営業責任者 |
| 予測誤差 | 予測時点ごとの予測額と実績額の差。組織・商品・ステージ別にBiasも確認 | Forecast・受注 | 週次/月次 | 営業企画 |
| データ重複率 | 承認した一致ルールで同一顧客候補となったレコード÷対象顧客 | CRM/MDM品質 | 月次 | データオーナー |
| 重要項目鮮度 | 定義した更新期限以内に更新された重要項目の割合 | Field History/監査 | 週次 | プロセスオーナー |
| 役割別有効利用率 | 役割ごとの主要行動を定義頻度で完了した利用者÷対象利用者 | 利用・操作ログ | 月次 | プロダクトオーナー |
| 変更失敗率 | リリース後にロールバック・緊急修正・重大障害を生じた変更÷全変更 | DevOps・障害 | リリース | CRM CoE |
最初の90日で確立すること
期間は対象範囲と意思決定速度で調整します。構想を文書で終わらせず、限定範囲で運用可能性まで確認します。
- 1〜2週WAVE 01価値仮説、役割別KPI、対象範囲目的承認
対象顧客ライフサイクル、業務成果、利用者、意思決定を合意
- 3〜4週WAVE 02As-Is、摩擦、品質・技術課題現状合意
BPMN、データ、利用ログ、自動化、連携、負債を診断
- 5〜6週WAVE 03To-Be、データモデル、主要ADR設計承認
プロセス、データ、権限、自動化、統合の原則を決定
- 7〜9週WAVE 04設定、移行、E2Eテスト、教育案利用価値検証
一つの役割・シナリオを薄いE2Eで実装・利用試験
- 10〜11週WAVE 05Runbook、CoE運営、KPIダッシュボード運用受入
リリース、監視、品質、問い合わせ、権限棚卸しを運用試験
- 12〜13週WAVE 06改善バックログ、展開ロードマップ拡張承認
利用・成果・負荷を評価し次シナリオと廃止を決定
典型的な失敗と予防策
失敗の症状だけでなく、構造原因と予防策を一つの因果線で確認します。
利用目的と判断者が不明
入力項目を増やす
To-Be業務と標準機能を検討していない
現行Excelを再現
標準・設定・コードの判断基準がない
カスタマイズが増殖
日常業務の価値と管理行動が変わらない
研修だけで定着を狙う
設計・導入前によくある質問
- 入力率を上げれば定着しますか
- 入力が意思決定、顧客対応、引継ぎ、自動化へ価値を返す必要があります。役割別に不要項目を削り、自動取得と利用フィードバックを設計します。
- Salesforce標準へ業務を合わせるべきですか
- 標準を出発点にしつつ、差別化価値・法令・顧客体験・運用能力で差分を審査します。差分は所有者と見直し条件を持たせます。
- AIで営業予測を改善できますか
- ステージ、活動、顧客、商品、実績の意味と品質が安定し、評価・監視・人の判断責任を定義できる場合に効果を検証します。
- 大規模改修と段階改善のどちらですか
- データモデルや権限の根本問題と、画面・自動化の局所問題を分けます。薄いE2Eで価値を確認しながら基盤変更を段階化します。
参照する一次資料
案件では対象範囲と最新版を確認し、必要な部分を適用します。フレームワークへの形式的準拠自体を目的にはしません。
NEXT STEP
課題、対象範囲、判断事項を整理します
製品や方式が未確定でも構いません。現状、期限、関係部門、止められない業務、既に決まっている条件を確認し、次に決めるべき事項を明確にします。