久しぶりの投稿です。3か月も空いてしまいましたが、前回投稿の続きでSalesforce案件の要件定義注意点について書きます
そもそも要件定義とは何をするものか？
前回の投稿でも書きましたが、従来のSI案件であれば、顧客のやりたいことを具体化してまとめ、その実現方法をざっくり考えるということだと思っています。
そのため成果物としては、「業務要求一覧」や「画面一覧」「帳票一覧」「バッチ処理一覧」「テーブル定義書」などが作成されると思います
これらの資料はシステムに必要な機能を表したものなので、SIのプロジェクトにとっては必要不可欠ですが、Salesforceの案件の要件定義をこの資料を作成を目的にしてしまうと失敗します。
Salesforceを購入したお客様はSalesforceを使って受注成約率や商談件数の増加など、つまり成功することを目的に導入されることがほとんどです。
そのため、システム要件の実現を目的に要件定義を進めてしまうと、プロジェクト後半に「思っていたものと違う」と言われてしまうことになります。注意が必要です。
システム要件を具体化するのではなく、使いかたを具体化するというのが目的です。システムベンダーとしてはおかしいと思われる方もいらっしゃると思いますが、顧客が使い方を目的にしている以上、変えようがありません。
SalesCloud、いわゆるSFAをやりたいお客様なら
- 商談フェーズごとの重要項目やフェーズ更新基準
- 日報など報告業務
- 営業マンの評価基準、KPI
などを画像の資料をつかって打ち合わせで決めていくことになるのです
はじめに顧客と認識を合わせる
このような使い方を決めていくプロジェクトで注意することは何か？
まず最初にお客様と検討すべき点について認識を合わせることです。
よくあるのは、ベンダーがお客様に対して現状の管理資料、商談管理シートや顧客台帳などの提示を求め、そに基づいてカスタマイズすることです。
このやり方でカスタマイズを行いミーティングで検証をしても現状業務とのギャップを検証することしかできなくなります。
その結果、フェーズのステップやフェーズごとに確認すべきことなど営業プロセスの見直し部分までプロジェクトミーティングの中で検討されなくなります。
これを防ぐにはまずプロジェクトのキックオフミーティングでフェーズ管理を含めSalesforceの基本的な使い方をお客様に説明し理解いただくことが必要です。
顧客が商談フェーズの使い方を理解した後に
「フェーズごとに必要な項目を出してください」と言うことで検討されたものが提示されます。
資料提示を依頼する前に、Salesforceの基本的な使い方について認識を合わせておくということが注意すべき点です。
しかし稀に、従来から使っていたエクセルの管理シートがSalesforceを使った業務に合わず、そのまま残ってしまうこともあり、顧客の意向に沿えないこともあります。
このような場合でも、簡単に妥協するのではなく、理解を得るたの資料など準備が必要です。
システム要件を具体化するプロジェクトと違って、顧客の理解を得るための作業が多いと理解しておく必要があると思います。