関係者管理責任の検討
プロジェクトはそれぞれ異なるため、業務コンサルタントとしては、関係者と対話を行うのが一般的です。 これは通常、プロジェクト マネージャーやソリューション アーキテクトなどの他のチーム メンバーと一緒に行います。 関係者とのこのコミュニケーションは、会議、メール、ワークショップ、ドキュメントを通じて行います。 チームのリーダーシップは、各チームメンバーに、プロジェクトの役割の上でどのような種類の関係者間コミュニケーションが予想されるかを知らせておく必要があります。
ワークショップの実施
ワークショップは、実際のプロジェクト作業が開始される前に始めることができます。 要件の収集、要件の確認、また追加要件の収集は、すべてクライアント ワークショップで行えます。
メーカー チームと協力して、要件と要件の実行に関する理解を深めましょう。 その後、チャンピオンから情報を識別して収集します。エンドユーザーの熱意を高めるために強調表示すべきシステムの領域がどこか、インプットを求めます。 競合やビジネス目標の追跡などのシステムの採用に対するユーザーへのインセンティブを提供するよう、経営陣を奨励します。 ユーザーの確約と採用を追跡する測定可能な方法を見つけ、システムの紹介および後のフェーズで潜在的な改善が可能な領域の特定を行います。
また、ワークショップでは、構築したシステムを関係者に引き継ぐ準備も行います。 この知識の伝達は、構築側から保守側へと行われることがあります。あるいは、そのために新規ユーザーをオンボードすることもありえます。 すべてのプロジェクトにこれらのワークショップを計画するための専任リソースがあるわけではありません。 業務コンサルタントは、技術者と企業間の橋渡しとして、この役割を引き受ける準備を万端にすべきです。
多くの場合、業務コンサルタントは、エンド ユーザーへのトレーニングの提供を支援します。 これもまた、技術とビジネスの両方を理解し、ユーザーとの溝を埋めることができる彼らのユニークな立場に基づいています。
ソリューションのレビューの作成と提供
ソリューション レビューは、関係者が目標に向けての進捗状況を示す機会です。 具体的な納品方法によりますが、進捗状況を段階的にレビューすることになるでしょう。 また、ソリューション レビューでは、チームに概念実証を提示し、意見やサポートを得ることができます。
ソリューション レビューはソリューション アーキテクトが主導することが多いですが、細かい部分は業務コンサルタントが担当することが多くなります。 ソリューション レビューを計画する際には、承認を得るだけでなく、真のフィードバックを求める方法を考えてみましょう。 ある機能が計画通りに実現しなかった場合や、設計時のようにスムーズに動作しなかった場合など、細かい軌道修正を計画できるタイミングです。 こういったレビュー サイクルでコース修正が指摘されても、気にしないでください。レビューはそのために行われているのですから。 フィードバックをどのように活かしていくかが重要です。
デモおよび概念実証の作成 (POC)
ソリューションの構想を始めたら、優れたデモを共有する時期かもしれません。関係者に要件を確認できるだけでなく、プラットフォームへの信頼を構築することができます。 プラットフォームに対する顧客の信頼が高くなると、提案したソリューションにより関心を持って受け入れる傾向が強くなります。 ソリューションに対して反復手法をとる場合は、途中で小規模な概念実証を複数作成する状況になることもあります。 Microsoft Power Platform により、概念実証の作成が容易になります。
デモは、提案するソリューションに応じて、さまざまな形を取る場合があります。 次に最も一般的な方法をいくつか紹介します。
- 標準状態 - 標準状態のデモは、カスタマイズされていない 1 つまたは複数のアプリケーションを表示するだけです。 このデモは、プリセールスのリソースによって実行されることが多く、ソリューション アーキテクトの関与はありません。 また、このデモは、製品のコア機能について顧客に最新の情報を提供するのに良好な方法です。 この方法のマイナス面は、顧客がアプリ上でそのソリューションの動作を思い浮かべるのには役立たないということです。 ビジネスに関わるサンプル データを含めることで、この方法のマイナス面の一部を軽減できます。
- ビルド済みデモ – 多くのパートナーは特定の業種やソリューション領域を専門としており、独自の知的財産が含まれるビルド済みデモを作成することに投資します。ビルド済みデモは、標準のベース ソリューションに独自に設計した付加価値を持たせたものです。 このアプローチでは、アプリ内の垂直的な言語が使用されることが多いため、顧客が具体的な問題領域を確認するのに役立ちます。 また、そのソリューション領域において顧客の気をそらす可能性がある不適切なものが非表示になります。
- プロトタイプ – 標準状態のデモをベースに、顧客のニーズを念頭に置いてアプリに最小限のカスタマイズを実行し、そのニーズを反映します。 プロトタイプの主なベネフィットは、デモの中で、具体的な目的の解決に顧客が関連付けることができる事例を紹介できる点です。
- 概念実証 – 概念実証は、ある概念が機能することを証明するためにビルドする必要があり、一般的に提案されたソリューションの特定のコンポーネントやアクティビティが関与します。 一般的に完了までの明確なパスがあるプロトタイプとは異なり、概念実証では望ましい目標の達成のために複数のアプローチを試すことがあります。
プロトタイプと概念実証を交互に使用することは一般的であり、通常、顧客の観点からはその差異は問題になりません。 ここでの目標は、ストーリーを伝え、提案したソリューションに命を吹き込むことです。これにより、提案したソリューションによって問題が解決されるのを顧客が確認するのに役立ちます。 また、未知のデータを洗い出してリスクを削減する必要があります。
保持または廃棄
プロトタイプや概念実証をビルドするときは、ここで短時間で勝つことが必ずしもリリース可能なソリューションにとってのベスト プラクティスにはなるわけではないことを理解しておく必要があります。 ベスト プラクティスに従うことは難しいことではありませんが、アイデアをすぐに見せる必要がある場合は、より大きなソリューションを計画するために確立されたベスト プラクティスを使用するよりも、即興でアイデアを展開するほうが簡単です。 これは事前に決めておく必要があります。資産を繰り越すには、それら資産が自社の基準を満たしており、簡単に修正できないショートカットではないことを確認する必要があるためです。
期待の管理
このように、簡単にデモを作成して、提案したソリューションを見せることができるため、期待値の管理は重要です。 デモを行うと、顧客が「素晴らしい、いつ本番運用できますか!」と言うことも少なくありません。 これをうまく乗り切る最適な方法は、顧客に見せているものは完璧に見えるかもしれませんが、Go-live に必要なセキュリティ、自動化、その他機能拡張がすべて備わっているわけではないと率直に伝えることです。 重要な点は、話し合いを行うこと、そして顧客がデモはデモに過ぎないと理解していると想定しないことです。