Success by Design のフェーズ
Success by Design は、実施方法に関係なくソリューション アーキテクトが顧客とやりとりできるように作られています。 アジャイル プロジェクトでは、プロジェクトのライフサイクル全体を通して、一定量のフェーズやワークショップが反復される可能性が高くなります。 このガイダンスでは、Dynamic 365 実装のライフサイクルを、方法論にこだわらない次の 4 つの方法にマッピングします。
開始
実装
準備
運用
開始
開始フェーズでは、プロジェクト チームはビジネス要件を収集して検証する検出モードに入ります。このフェーズでは、高レベルのソリューション アプローチを確定後、すべてのスコープ内の作業一覧を定義するように入力し、これらの更新を反映してプロジェクト計画を変更します。 プロジェクト チームが高レベルのソリューション設計を作成し、関連するプロジェクトの作業ストリームの大部分が定義されると、Success by Design はソリューション ブループリントのレビューを開始します。
開始フェーズは展開の成功に影響を及ぼす多くの意思決定が行われるため、プロジェクトの最も重要な部分の 1 つです。 このフェーズを急いで終えてシステムの構築に取りかかりたくなることもありますが、構築を開始する前に計画と設計を念入りに行うことが重要です。
開始フェーズでは、プロジェクトは通常、検出モードにあります。このフェーズでは、ビジネス要件を収集して上位レベルのソリューション アプローチを決定し、作業のスコープを計画します。
理想的には、ソリューション アーキテクトがこのフェーズに関与し、Success by Design、関連性のあるワークショップ、主な成功判断基準などを紹介します。 また、ソリューション アーキテクトはソリューション ブループリント ワークショップとスケジュールを提案します。
プロジェクト チームは、検出フェーズのマインドセットで、サービス、テナント管理、製品の適合性などに関する具体的な質問をしてくることがあります。 ソリューション アーキテクトは、このような質問に答えることができます。
チームが上位レベルのソリューション アプローチを策定後、主要な統合を特定し、上位レベルのプロジェクト計画を準備したら、ソリューション ブループリント ワークショップを計画して実施する必要があります。
また、ソリューションのブループリント ワークショップ レビューでは、複雑なデータ モデル、大規模なデータ移行、統合など、より複雑な領域に注目して、それぞれの実装ワークショップを計画する必要があります。
プロジェクトのステージと進捗状況に関係なく、ソリューション ブループリント ワークショップは重要な作業であり、すべてのエンゲージメントに対して実施する必要があります。
実装
実装フェーズでは、プロジェクト チームは合意したソリューションの設計と範囲に従ってソリューションを構築することに重点を置きます。 このフェーズでは、実装に関するレビューが導入され、ソリューションの設計図のレビューの結果と推奨事項が通知されています。 実装のレビューは、ソリューションの設計 (データ モデル、セキュリティ、統合) と実装のプラクティス (ALM とテスト戦略) の特定の側面に関連する質問に入念に対処するために使用されます。 実装では、ソリューションの設計図のレビュー中または後に特定されたリスクに完全に対処します。その後、ソリューションが構築される前に、プロセスの過程で非常に多くの問題が発生します。
実施方法 (ウォーターフォールまたは反復) にかかわらず、ソリューション アーキテクトは、ソリューション ブループリント ワークショップ中に計画した実装ワークショップをスケジュールする必要があります。 ただし、具体的な方法は各プロジェクトの所有者が決定権を握っているものの、Dynamics 365 の実装には反復的またはアジャイルな実施方法、あるいはその組み合わせが最適であることを念頭に置いておくことが重要です。
コンポーネントの詳細な設計を完了する前に、実装ワークショップを計画する必要があります。
関連性がないか、リスクが低いと見なされるコンポーネントを対象としている実装ワークショップが存在する場合がありますが、このようなワークショップは省略できます。
実装フェーズでは、特定のコンポーネントの設計、テクノロジの選択、今後の変更、ロードマップ、廃止、アプリケーション ライフサイクル管理 (ALM)、およびビルドに関する疑問が生じることが考えられます。
開発するソリューションがベスト プラクティスに従っており、製品のロードマップに戦略的に沿ったものになるように、事前に顧客と対話するようにしてください。
準備
準備フェーズでは、ソリューションが構築およびテストされ、プロジェクト チームはユーザー受入テスト (UAT) とトレーニングの最終段階に向けて準備をしています。 また、必要なすべての顧客の承認、情報のセキュリティの確認、切り替え計画の定義 (実行/終了なしの基準を含む)、実行開始イベントのスケジュール、サポート モデルの準備が整いました。さらに、配置の実行ブックにはタスク、所有者、期間、および定義済みの依存関係が含まれています。 この時点で、プロジェクト チームは Success by Design Go-live 準備完了レビューを使用して、残りのギャップや問題を特定します。
また、システムの非機能要件 (現実的な実稼働負荷でのフォームの読み込み時間、検索のパフォーマンス、統合のパフォーマンスなど) を検証します。
顧客またはパートナーは、システムの運用準備が整っていることを確認するために、社内の承認、情報セキュリティのレビュー、侵入テストなどをすべて完了しています。
Go-live 後のサポート モデルが定義され、ビジネス部門の合意を得ています。
カット オーバー計画、Go-live 予定日、および承認/不承認条件に関してビジネス部門の同意を得ており、すべてのタスク、所有者、開始日、期間、ロールバック計画を含む運用展開計画が作成されています。
ソリューション アーキテクトは、Go-live 準備ワークショップを実施して計画を確認し、あらゆるギャップや問題を特定します。
また、プロアクティブなパフォーマンス チェックとソリューション チェッカーが実行されていることも確認します。
運用
アプリケーションの計画、開発、および展開が完了していますが、これで終わりではありません。 このフェーズの目標は、展開の成否を検証し、プロジェクトから学んだ教訓を見直して、次のフェーズへの移行、またはメンテナンス チームの移行に対するサポートを提供することです。
顧客の移行後に、ソリューション アーキテクトは Go-live 後のレビューを実施する必要があります。
移行計画について話し合い、メンテナンス チームともその計画を共有してください。