パイロット版の実行

小規模なビジネスエリアでエンドツーエンドの移行プロジェクトを完了させることで、大規模なビジネス中断のリスクを負うことなく迅速にデプロイすることができます。このエクスペリエンスは、比較的少ないコストで得られる価値提案 (能力、運用、コスト) に対する信頼感を高め、フルスケールのプロジェクトに対して多額の資金とリソースを投入することの正当性を裏付けることができます。

パイロット版は、エンドユーザーが新しいプラットフォームにどのように反応するかに基づいて、本格的なデプロイに向けた情報を収集します。収集した情報は、ステークホルダーが次のような実際のデータを使って重要な質問に答える際に役立ちます。

• 提供されているトレーニングは適切かつ十分か?

• エンドユーザーが実際に電話を受けたとき、新しいプロセスが正しく機能しているか?

• ユーザーがデバイス上の他のアプリケーションに気を取られていないか?

• アーキテクチャやパターンがライブ環境で期待どおりに機能しているか?

ベストプラクティス

• パイロット版がスプリントの早い段階で、最小限の愛すべき製品 (MLP) の最初のデリバリーに含まれることが理想です。

• パイロット版の参加者として、テクニカルユーザー、ビジネスユーザー、エンドユーザーを含める必要があります。

• ステークホルダーにインタビューしてシステムの使用方法に関する事例フィードバックを得たり、平均処理時間や離脱率などのデータを収集して、新しいシステムを以前のプラットフォームと比較したりします。ステークホルダーにインタビューを行い、システムの使用方法に関する事例のフィードバックを得て、平均処理時間、放棄呼率などのデータを取得し、新しいシステムと以前のプラットフォームを比較します。 

• パイロット版の実行中に特定した微調整や修正は、完了まで追跡するようにしてください。 

• パイロット版を開始する前に、成功基準と次のステップを定義します。成功基準は、成功/失敗の判定を下す決定的なスコアリングが可能なデータ駆動型にする必要があります。ステークホルダーがパイロット版とデリバリー計画を承認して修正を加えたら、あらかじめ定義されている次のステップ (フルスケールのデプロイの開始など) が開始されます。

• パイロット版で、変更や再設計が必要な分野が明らかになった場合でも、心配する必要はありません。これはパイロット版の貴重な成果であり、本番稼働のデプロイを成功させる基盤となるものです。推奨事項がまったく提供されないパイロット版では何の価値もありません。このような結果になると、パイロット版の有効性に対して懸念が生じます。

パイロット版グループの選択

ソリューションのパイロット版として選択した事業分野で、ビジネス上の成果を達成するために、最小限の愛すべき製品 (MLP) の範囲に含まれるすべての機能を実証することが理想的です。MLP のデリバリーの成功が、複雑性の構築とサービス機能の追加を行うための出発点となります。MLP パイロット版グループは次のことを行う必要があります。

• 重要度の低いビジネス領域 (社内ヘルプデスクや状況変更の通知) を表します。

• ユーザーが新しいプラットフォームを学習し、フィードバックや観察を記録できるように、少ない件数の電話に対応します。

• プロジェクトチームとステークホルダーからの信頼を得て、フィードバックの公正さ、正確性、客観性を保ちます。これにより、パイロット版の結果への信頼性を浸透させ、共同開発環境を構築することができます。

• 対象となるプラットフォームの機能の大部分を実行します。フルスケールのデプロイの対象となる機能の 10% しか使用しないパイロット版には、価値や関連性はほとんどありません。

• 技術的な制約 (リモートワークなど) やライセンスの理由により、古いプラットフォームから除外されていた機能や完全に統合されていなかった機能を実行します。古いシステムにレポートや記録がないグループから開始すると、レガシー統合の構築やレガシーデータの移行が必要なくなる場合もあります。それでも、パイロット版が引き続きフルスケールのデプロイを表していることを確認する必要があります。

実際には、組織内のチームがパイロットに参加する能力や意欲によっては、これらの項目のいくつかについて妥協が必要になる場合もあります。