デモの作成と検証
提案するソリューションの構想を開始するにあたって、関係者に要件を確認し、プラットフォームに対する信頼を高めるために、関係者とデモを共有することを検討する場合があります。 プラットフォームに対する顧客の信頼が高くなると、提案したソリューションにより関心を持って受け入れる傾向が強くなります。
デモは、提案するソリューションに応じて、さまざまな形を取る場合があります。 次に最も一般的な方法をいくつか紹介します。
標準 - この種類のデモンストレーションは、カスタマイズのない 1 つまたは複数のアプリをハイライトします。 このデモは、プリセールスのリソースによって実行されることが多く、ソリューション アーキテクトの関与はありません。 この方法は、製品のコア機能について顧客に最新の情報を提供するのに効果的な方法です。 このアプローチのマイナスの側面は、顧客がアプリ上でそのソリューションの動作を思い浮かべるのには役立たないということです。 この問題は、ビジネスに関わるサンプル データを含めることで軽減できます。
ビルド済みデモ - 多くのパートナーは特定の業種やソリューション領域を専門としており、独自の知的財産が含まれるビルド済みデモを開発することに投資します。ビルド済みデモは、標準のベース ソリューションに独自に設計した付加価値を持たせたものです。 このアプローチでは、アプリ内の垂直的な言語が使用されることが多いため、顧客が具体的な問題領域を確認するのに役立ちます。 さらに、この種類デモでは、そのソリューション領域において顧客の気をそらす可能性がある不適切なトピックが非表示になります。 一般に、ソリューション アーキテクトはこのビルド済みソリューションのデモンストレーションには関与しませんが、その構成のいずれかの段階での支援に関わってくる傾向にありました。 実際、ソリューション アーキテクトは、同じプロトタイプを繰り返し構築していることに気付いたとき、潜在的にビルド済みソリューションのデモンストレーションを提示することを検討するのが当然です。
プロトタイプ - このアプローチは標準状態のデモをベースに、顧客のニーズを念頭に置いてアプリに最小限のカスタマイズを実行し、そのニーズを反映します。 この方法の主な利点は、ソリューション アーキテクトを支援することです。
デモの中で、具体的な目的を解決しようとしているときの事例を紹介し、顧客が関連付けることができるようにします。 ソリューション アーキテクトは、思い描いたソリューションを使用して、顧客が自身の目標を特定するのを支援することに関与することが多く、プロトタイプをビルドするか、チームがプロトタイプを制作するよう案内することを支援します。概念実証 - 概念実証は、ある概念が機能することを証明するためにビルドする必要があり、一般的に提案されたソリューションの特定のコンポーネントやアクティビティが関与します。 この方法は、たびたび設計フェーズ中に実行されますが、プリセールス中に顧客がその概念が提案されたソリューションのコンテキストで機能することを確認する必要があるときにも使用されます。 ソリューション アーキテクトは、一般的にこの方法の必要性に拍車をかけ、その取り組みの推進に関わっています。 一般的に完了までの明確なパスがあるプロトタイプとは異なり、概念実証では望ましい目標の達成のために複数のアプローチを試すことがあります。
プロトタイプと概念実証を交互に使用することは一般的であり、通常、顧客の観点からはその差異は問題になりません。 ストーリーを伝え、提案したソリューションに命を吹き込むという目標に焦点を定めてください。これにより、提案したソリューションによって問題が解決されるのを顧客が確認するのに役立ちます。 また、現在顧客が抱えている問題に寄与する可能性がある未知の問題を排除することで、リスクを軽減することも検討してください。
ソリューション アーキテクトの関与
ソリューション アーキテクトは、営業チームと協力して、デモの内容と使用するアプローチ (標準とプロトタイプのどちらを使用するかなど) を明確にすることに関与する必要があります。
プロトタイプや概念実証のビルドにソリューション アーキテクトがどれだけ関与するかは、プロジェクトによって大きく異なります。 一般的に、これらの取り組みには複数のスキルセットと、ビルドにだれが関与する必要があるかについての判断ポイントが関わってきます。 ソリューション アーキテクトは、すべての作業を自分で実行すると数時間で済むことが、さまざまなリソースで構成されるチームをコーディネートし、その必要性について説明するのに数週間かかる場合があることに気付くことがしばしばあります。 ソリューション アーキテクトは、自分で作業を完了することに利点がない状況で、他のリソースを巻き込むようにする必要があります。
保持または破棄
プロトタイプや概念実証をビルドするときは、短時間で勝つことが必ずしもリリース可能なソリューションにとってのベスト プラクティスにはなるわけではないことを理解しておく必要があります。 ベスト プラクティスに従うことは難しいことではありませんが、アイデアをすぐに見せる必要がある場合は、より大きなソリューションを計画するために確立されたベスト プラクティスを使用するよりも、即興でアイデアを展開するほうが簡単です。 このアプローチは事前に決めておく必要があります。資産を繰り越すには、それら資産が自社の基準を満たしており、簡単に解決できるショートカットではないことを確認する必要があるためです。
期待の管理
提案したソリューションを紹介するデモを作成するための労力はほとんどありません。したがって、期待を管理することが重要です。 一般に、デモが提供されると、顧客は直ちにその提案を受け入れ、ソリューションをライブに移行できるタイミングについて聞いてきます。 このシナリオをうまく乗り切る最適な方法は、顧客に見せているものは完璧に見えるかもしれませんが、Go-liveためには必要なセキュリティ、自動化、その他機能拡張が備わっていないことを率直に伝えることです。 デモはあくまでもデモンストレーションであり、最終的なソリューションでないことを顧客は理解していると見なすのではなく、すぐに話し合うことが重要です。
演習: Woodgrove Bank のデモ
Woodgrove Bank の将来のデモを計画する際には、次の質問を参考にしてください。
- Woodgrove Bank 用には、どの種類のデモを作成しますか?
- 特別な機能を紹介する優れた概念実証のアイデアを作成することはできますか?