営業のプロセス
重要
Dynamics 365 Project Service Automation は Dynamics 365 Project Operations に進化しました。 詳細は、Project Service Automation の移行を参照してください。
適用対象: Project Service アプリ バージョン 3.x
プロジェクトベースの組織で使用される営業プロセスは、製品ベースの組織で使用される営業プロセスとは異なります。 この違いは、プロジェクト・ベースの組織の販売サイクルが長く、各取引の見積を分析および作成するためにカスタマイズされた見積の技量が必要なために発生します。 Dynamics 365 Project Service Automation は、Dynamics 365 Sales の営業プロセスで使用されているものと同じ機能を使用します。 ここに例を示します。
- 営業プロセスを追跡にあたっては、潜在顧客エンティティが使用されます。
- 潜在顧客の見込み評価は、営業案件として追跡されます。 営業プロセスは営業案件から開始することができます。
- 営業案件のすべての関連するアーティファクトにアクセスします。 これらのアーティファクトには、営業チーム、利害関係者、見込み、評価、営業段階とビジネスプロセスが含まれています。
- 1つの営業案件に対して複数の見積もりが作成されます。
- 見積もりは、受注を作成するための 受注案件として成約 としてマークされます。 PSAでは、受注はカスタマイズされ、プロジェクト契約と呼ばれます。
以下の図はプロジェクトベースの組織における一般的な営業プロセスを示ししています。
営業の見積もり
営業の値は、以前に提供されたプロジェクトとプロジェクトの複雑さに基づいて見積もることができます。 過去のプロジェクトに対する拡張機能を含むプロジェクトや、ベンダーの専門知識が高く、よく知られた作業テンプレートが使用されているプロジェクトの場合は、簡単な見積もりプロセスを使用できます。 通常はプロジェクトが複雑化すると、購入プロセスもさらに長くなります。 そのため、売上予測のプロセスには多くの段階があります。 プロセスの初期段階で、営業チームは、取引先企業のマネージャーと各カテゴリの専門家 (SMEs)からの情報を使用して、見積りが作成された個々の作業コンポーネントごとに高レベルの見積りを作成します。 作業のこれらのコンポーネントは、見積明細に表示されます。
高品質の見積を作成できます。 最終的には、この高レベルの見積もりは、標準化されたプロジェクト・テンプレートを使用して作成するプロジェクトの計画に基づいた、より詳細な見積もりに置き換えられます。 これらのテンプレートを使用すると、スケジュールを作成し、見積とその構成要素(見積明細)の金額を決定することができます。
1つのプロジェクトに対して複数の見積を作成し、単一の営業案件エンティティ・タイプにグループ化することができます。 これらの見積もりは最終的に 受注案件として成約としてマークされ、プロジェクト契約または作業明細書(SOW)が作成されます。 プロジェクト契約には、顧客が受け付ける各コンポーネント (契約品目) の契約値を保持しています。 SOWは通常は Microsoft Word ドキュメントとして作成されます。 プロジェクトの実施中に顧客に送信されるすべてのインボイスは、プロジェクト契約、またはSOWを参照します。
また、1つのエンティティ・タイプの下に代替見積を作成したり、見積の成約時にプロジェクト契約が作成されるようにシステムを設定できます。 この場合は、SOWを意味するWord文書をプロジェクト契約レコードに添付することができます。
営業プロセスの設定
Microsoft Dynamics 365 のビジネス プロセス フロー(BPFs)を使用して営業プロセスを構成することができます。 BPFsは、営業担当者が会社組織の慣れ親しんだ取引段階を使用できるよう、ガイド付きのビジュアルインターフェイスを提供します。
たとえば、以下のような6つ営業プロセスの段階があるとします:
- [見込みありと評価]
- 見積もり
- 内部レビュー
- 契約
- 実行
- [閉じる]
この6つのステージは、山形マーク(>) で表されており、作成された各営業案件エンティティタイプを展開します。
進展の過程で、同じ取引を表す異なるエンティティを使用する場合もあります。 営業プロセスの初期段階では、取引は営業案件エンティティとして表されます。 時間の経過とともにさらなる詳細情報が追加されると、見積りの作成にあたって高水準の概算が必要になります。 これらの見積もりが内部と顧客の利害関係者が見直されれば、見積もりのエンティティは取引を意味します。 顧客は見積もりを承諾した後、プロジェクト契約やSOWは、取引を意味します。 この動作をサポートするために、BPFsはプロセスの各ステージが異なるデータベース・テーブルにリンクされるように構成されています。
営業プロセス 見込みありと評価する ステージは営業案件エンティティによって支えられています。 見積もり および 内部レビュー ステージは、見積もりエンティティによって支えられています。 契約、 納品、 成約ステージはプロジェクト契約エンティティによって支えられています。
各段階で取引を遷移していくと、適切なエンティティ・レコードを作成するように求められます。作成したエンティティ・レコードは、プロセスの進行に役立ちます。 ステージには条件を指定することができます。 たとえば、見積にカスタム価格表が使用されている場合にのみ見積の内部レビューが必要な場合は、ビジネス・プロセスの適切な段階でその条件を構成することができます。 内部レビュー ステージは、カスタム価格表を使用する見積にのみ表示されます。 その他のすべての取引と見積もりについては、 見積もり ステージは 契約 ステージの後に続きます。
Note
PSAには、営業案件、見積もり、受注、請求書関連のエンティティに特化したページがあります。 これらのエンティティのプロジェクト情報ページを使用して、Project Service の営業案件、見積もり、受注、請求書を作成する必要があります。 別のページを使用してレコードを作成すると、 プロジェクト情報 ページからレコードを開くことができません。 プロジェクト情報 ページからレコードが開くには、 プロジェクト情報 ページを使用して、レコードを削除して、再作成する必要があります。 プロジェクト情報 ページの、これらの各エンティティー・タイプのビジネス・ロジックによって、レコードの タイプ フィールドが正しく設定され、必須となる構想がすべて適切に初期化されます。
Project Service Automation と Sales の違い
PSAの営業プロセスではSalesの営業プロセスの基本的な機能を使用していますが、プロジェクト・ベースの組織のビジネス・プラクティスが異なるため、いくつかの重要な違いがあります。 ここに例を示します。
- プロジェクトの見積もり – Project Service Automation では、見積からプロジェクト契約が作成された後、見積がクローズされます。 Sales では、成約後も見積をオープンのままにすることができます。 この違いは、プロジェクト・ベースの組織には、見積とプロジェクト契約が合致することが適しているためです。
- アクティブ化とリビジョン – PSAでは、アクティブ化とリビジョンはプロジェクトの見積もりに対応していません。 Salesでは、見積もりをロックして、さらなる編集ができないようにすることができます。
- 見積もりを成約、失注としてクローズする – PSAでは、プロジェクトが成約/失注としてクローズされても、営業案件はオープンの状態にとどまります。 その他すべての営業案件の見積もりは失注としてクローズされます。 Salesでは、見積もりが成約/失注としてクローズされると、営業案件をどのように扱うかを促されます。 ユーザーの入力内容によって、営業案件はクローズされるか、オープンのままになる可能性があります。
営業サイクルにおける見積およびプロジェクト計画のリビジョンの追跡
PSAでは、見積もりに対するリビジョンを追跡することができません。 その代わりに、既存の見積もりを 失注としてクローズ としてマークし、新しい見積もりを作成する必要があります。 PSAを使用して、見積もりのコピーやプロジェクトベースの見積書のクローンを作成することができます。
見積およびプロジェクト契約の注釈と承認の追跡
レコードウォールとポストを使用して、見積とプロジェクト契約のレビューと承認を管理することができます。 カスタムワークフローとプラグインを作成して、レビューおよび承認作業項目に対する通知の割り当て、リダイレクト、エスカレーション、および管理を行うことができます。