ソリューション コンポーネントを特定する
探索プロセスでは、いくつかのソリューション案を明確化していく必要があります。 このユニットでは、顧客に提示するソリューション案に使用できる可能性がある、ソリューション コンポーネントを特定する方法について説明します。 これはプロジェクトのプリセールス フェーズなので、目標は、提示したソリューションが実際の構築後にどのようなものになるかを顧客に示すと共に、そのソリューションによって目標がどのように達成されるかを説明することです。 また、このフェーズは、製品のロードマップについて検討すると共に、コンポーネントをどのように実装すれば、イテレーションを通じて迅速に価値を示すことができるかを検討する良い機会でもあります。
ニーズを機能にマッピングする
顧客とのミーティングを通じて、顧客の主なニーズは既に把握していることと思います。 コンポーネントを特定するには、それらのニーズを全体的に検討したうえで、それらのニーズを、既存の Dynamics 365 アプリか、カスタムの Microsoft Power Platform アプリか、場合によってはカスタム プログラムにマッチングする必要があります。 大規模なプロジェクトの場合は、複数のアプリや、3 つのカテゴリすべてにマップする必要が生じることもあります。
すべてのプロジェクトが一から着手されるわけではありません。多くの場合は、既存のシステムが既に配置されていて、それらを強化または統合するかたちでプロジェクトが進められます。 たとえば、Dynamics 365 Customer Service を使用していて顧客が、特定のニーズに対応するために、いくつかのオムニチャネル機能を追加するようなケースもあるでしょう。
ニーズによっては、複数のアプリが対応付けられる場合もあります。 たとえば、営業のニーズに対して Dynamics 365 Sales をマッピングし、既存の Dynamics 365 Finance に対して、コミッション追跡と支払に関する機能強化を施すといったケースも考えられます。
マッピングや提案を行う際には、交換または追加するアプリが、顧客の使用する既存のアプリと重複していないかどうかについて注意しましょう。 そうなることを前提とした要請に対応するのであれば問題ありませんが、 顧客が Microsoft 製以外の ERP を既に使用している場合に、ソリューションの展開を容易にする目的で Dynamics 365 Finance の追加を提案した場合、その提案は受け入れられないでしょう。
重要なソリューション コンポーネントについては、用意された機能をそのまま使用する部分と、カスタムの機能が必要になる部分をはっきりさせることをお勧めします。 たとえば、製品コンフィギュレーターを除くすべての機能について、これまで標準の営業機能が使用されていたことを確認したうえで、 製品コンフィギュレーターのソリューション案を検討するようにしましょう (たとえば、カスタムの PowerApp をアプリに組み込んだり、サードパーティのコンフィギュレーター ソリューションを提供するなど)。
イメージ図を使用して複雑なアイデアを説明する
ソリューションを理解しやすくするには、1 ページの図を作成すると効果的です。 図では、システムを操作するペルソナを複数含めることで、さまざまなユーザーがそのソリューションをどのように使用するのかを明確に示すことができます。 あまり詳しい情報を追加することは避けてください。そのようにすると図が見にくくなり、アイデアが伝わりづらくなる可能性があります。 簡潔でわかりやすい図にしておけば、その後のディスカッションでもアイデアの基点として使用できますし、他社との差別化にもつながります。 詳しい説明が必要な箇所がある場合は、その領域にフォーカスした関連図を別途作成することができます。
データ モデリング
正式なデータ モデリングは、ソリューションの設計プロセスの一環として行われ、通常は契約の締結後に行われます。 ただし、プリセールス フェーズでは、大きなデータ ピースとその配置先を特定するために、大まかなデータ モデリングの概念化が何度も実行されます。 この作業は、概念実証が終わった後、顧客に提示したソリューションを試作する目的でよく行われます。 また、データ モデリングに関するこれらのインサイトは、データ モデリングの思考プロセスをスムーズに開始するために、設計プロセスにも反映されます。 データ モデルについては、概要版と詳細版を作成し、共有することを検討してください。 詳細モデルは、システムの設計や構築を行う担当者用として使用します。 概要モデルは、ソリューションの全体像を示すためのものです。具体的な詳細について知る必要のない、その他の関係者用として使用します。
プロセス モデリング
探索フェーズでは、顧客の主要プロセスについても確認したことと思います。 ソリューションを提案する際には、そのソリューションによって顧客の主要なビジネス プロセスをどのように達成できるのかを説明することが不可欠です。
場合によっては、提示するプロセスが顧客の既存のプロセスと類似したものになることもありますが、多くの場合は、既存のものとは違ったものになります。 ソリューション コンポーネントを特定する際には、その相違点を明確化することが重要です。そのうえで、そのプロセス案によって顧客の目標がどのように達成されるかを確認する必要があります (サポート案件の解決を 20% 迅速化すると共に、情報提供機能を強化するなど)。
ユーザー エクスペリエンス
顧客は、常にユーザー エクスペリエンスを重視します。 探索フェーズでは、モバイル機能が常に必要なのか、場合によって必要なのか、それとも一切必要ないのかについて、詳細を確認したことと思います。また、ユーザー エクスペリエンスに関するその他のニーズも確認されたかもしれません。 提案するソリューション コンポーネントを決める際には、それらのニーズをマッピングすることが重要となります。 必要であれば、ソリューション案を説明する概念実証やワイヤーフレームを使用して、それらのコンポーネントのデモを示すようにしましょう。
ワイヤーフレームには、必要に応じて次の要素を含めます。
メイン フォーム
ダッシュボード
モバイル エクスペリエンス
ビジュアル化要素 (たとえば、Power BI)
次の図は、ワイヤーフレームとそのワイヤーフレームから作成する実際のフォームを例示したものです。
統合
ほとんどのソリューションは、独立して存在するわけではなく、内部または外部的な統合によって実現されます。 それらの統合がどのように処理されるかは、ソリューション コンポーネントを決定していく過程で見えてきます。 このプロセスには、統合を完了するために使用するツールやサービスを定義する作業が含まれる場合があります。 マルチシステムのソリューションでは、1 つのシステムから別システムへと処理が受け渡される、明確な境界を定義する必要があります。 これらの境界が、構築を担当する組織と保守を担当する組織の間での、"契約" の発生ポイントとなります。 これらの境界で何が起こるかを見極めたうえで、だれがインターフェイスを構築し、だれがそれらを使用するのかを明確に定義しましょう。 これを定義することは、サードパーティのサプライヤーや社内の開発チームが参加する場合には特に重要となります。
展開オプション
Microsoft は、Microsoft Dynamics 365 をサブスクリプションベースのモデルで提供しています。 このオプションを使用すると、Dynamics 365 にクラウドからアクセスでき、IT ネットワークのハードウェアやソフトウェアのライセンスに投資する必要がありません。 アプリケーションをローカルに展開する必要がなく、ユーザーは複数のブラウザーから Dynamics 365 にアクセスできるようになります。 このアクセスは、リモートまたはオフサイトで働くスタッフにとって非常に重要です。
ただし、Dynamics 365 Finance と Dynamics 365 Supply Chain Management (旧称: Dynamics 365 財務と運用) は、オンプレミスで展開することもできます。これは、組織がアプリケーションをローカルに配置できることを意味します。
次の Dynamics 365 アプリケーションについては、展開に Lifecycle Services を使用する必要があります。
Dynamics 365 Finance
Dynamics 365 Supply Chain Management
Dynamics 365 Commerce
その他の Dynamics 365 ビジネス アプリケーション (次の一覧に示すものを含む) については、標準の開発/テスト/実稼働環境を使用して、オンラインで展開するのが主要な方法となります。
Dynamics 365 Sales
Dynamics 365 Customer Service
Dynamics 365 Customer Insights - Journeys
Dynamics 365 Field Service
また、試用環境を作成して試運転を実施することもできます。これにより、システムの立ち上げを数週間や数か月単位ではなく、数日単位で実施できるようになります。 稼働中のサーバーの保守やライセンス料金に対処する必要はもうありません。 さらに、ユーザー ライセンスは、仕入先を経由することなくオンラインで直接購入できます。また、ビジネスの成長に応じて必要が生じた場合には、ユーザーをオンラインで追加することもできます。
Dynamics 365 のビジネス アプリケーションでは、複数の種類の環境が用意されています。 環境の種類は目的ごとに選択でき、それによって環境の特性が決まります。
試用版 - 試用環境は、短期的なテストのニーズをサポートするもので、短期間で自動的にクリーンアップされます。
サンドボックス - 非実稼働環境です。Microsoft Dataverse のデータベース インスタンスに関連付けられた場合は、リセットなどの機能が提供されます。
実稼働 - 組織での恒久的な業務に使用されます。 管理者または Power Apps ライセンスを持つユーザーであればだれでも作成し、所有することができます。
既定 - 非カスタムの実稼働環境です。 各テナントでは、既定の環境が自動的に作成されます。
開発者 - 開発者環境は、コミュニティ プラン ライセンスを持つユーザーによって作成されます。 これらは所有者専用の環境となります。 この環境では、他のユーザーとの共有を行うことはできません。
Microsoft Dynamics Lifecycle Services
Microsoft Dynamics Lifecycle Services は、Microsoft Dynamics 365 Finance および Microsoft Dynamics 365 Supply Chain Management 環境のアプリケーション ライフサイクル管理を支援するサービスです。 Lifecycle Services は、環境を提供すると共に、定期的に更新される一連のサービスを提供する、Microsoft Azure ベースのコラボレーション ポータルです。 このポータルは、顧客とそのパートナーが Finance および Supply Chain Management プロジェクトを管理するために使用できる、共同ワークスペースを提供するものです。 Lifecycle Services は、プリセールスから実装フェーズ、さらに実稼働環境 (クラウドまたはオンプレミス) で使用できます。 Lifecycle Services では、チェックリストとツールを使用してプロジェクトを管理できます (実装に役立つ事前構築済みメソドロジーの提供を含む)。
Lifecycle Services を使用すると、アプリケーションを管理するうえでの予測可能性、コラボレーション、および構造的手順を強化することができます。 Lifecycle Services の目的は、実装プロセスを簡素化し、標準化することで、実装の予測可能性、反復性、および品質を向上させることです。
次の手順
主要なソリューション コンポーネントが特定されると、次の手順が決まってきます。 たとえば、デモ用のソリューションを顧客用にカスタマイズする必要があるかどうかや、新しい概念実証/試作品を作る必要があるかどうかなどを踏まえて、次の手順を決定することができます。
このプロセスの目的は、完全なソリューションを詳細に設計することではありません。 あくまでも、これはまだプリセールスのフェーズです。ここでの目的は、提案するソリューションによって、顧客のニーズをどのように満たせるかを説明し、十分なソリューションが用意できることを顧客に示せるようにすることです。 それらの情報を整理することで、必要な価格設定を特定し、契約の締結とソリューションの構築に向けてスムーズに準備できるようになります。
演習: Woodgrove Bank の各チーム間での共通の用途を特定する
Woodgrove Bank の顧客プロファイル (特に、記載されている顧客対応チーム) を確認してください。 チーム内で共通のテーマを特定してください。 必要な機能がチーム間で重複していないかどうかを確認してください。 他のチームとニーズが大きく異なるために、個別のソリューションが必要となるチームがないかどうかを評価してください。