翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
運用のワークストリーム
運用のワークストリームは、技術基盤とユーザージャーニーのワークストリームをサポートします。このワークストリームには、移行全体を成功させるために不可欠な、非技術的なアクティビティの大半が含まれています。
このワークストリームには、労力や影響を最小限に抑えて変更または取り消しを行うことができる決定事項が含まれます。人の働き方や関わり方に基づいた製品仕様が、最初から完璧に仕上がっていることはほとんどありません。なぜなら、多くのステークホルダーや意見を考慮しなければならないからです。早期に関与し、幅広く頻繁に相談することが重要であるため、このワークストリームでは、アジャイルで反復的なアプローチが適しています。運用モデルやトレーニング資料の初期の下書きを作成することから始め、最終製品に到達するまで頻繁かつ迅速に反復します。
運用のワークストリームは、プロジェクトガバナンス、調整、運用モデルの定義、サービスの導入、トレーニングの 5 つのフェーズで構成されています。
プログラムのガバナンス
プログラムのガバナンスのアクティビティは、移行プロジェクトの全期間にわたって実行します。プロジェクトがどの段階にあるかにかかわらず、アクティビティは定期的 (ミーティングが定期的に開催される) に行われ、透明性が高く (プロジェクトチームにはリスクや問題を率直に提起する機会が与えられている)、ガバナンスが機能している (リーダーには権限が与えられ、それに応じて意思決定やエスカレーションを行う意思がある) 必要があります。これらは、問題を迅速かつ効果的に明らかにして、解決するために不可欠な要素です。
Alignment
これはプロジェクトの最初の正式なアクティビティであり、プロジェクトの範囲をビジネス成果に合わせて調整することに重点を置いています。調整は、ステークホルダーとの話し合いに基づいて、以前の計画や見積もりを検証し、調整する機会を提供します。
このアクティビティにおける主なアクションには以下が含まれます。
-
お客様の高レベルのユースケース、現在の技術的およびビジネス上の問題点、改善の機会を発見する。
-
望ましいビジネス成果について議論して合意し、それらの相対的な優先順位を決定し、成功基準を特定する。
-
高レベルのソリューション設計を作成し、それを使用してこの初期フェーズにおけるスコープとテクノロジーの選択を定義する。この高レベル設計は、後のフェーズで低レベル設計のアクティビティを加速させるための方向性を示す。
-
タイムラインと実装コストを検証する。
運用モデルの定義
このフェーズのアクティビティでは、誰がコンタクトセンターソリューションを使用し、ソリューションをどのように管理するかを定義します。運用モデルは、手順書、ランブック、設定ファイルのいずれでもありません。例えば、ログを取得してサポートチケットにアタッチする方法を説明したり、この手順のスクリーンショットを提供したりするべきではありません。そうではなく、誰がログを取得し、どのキューまたはベンダーに送信すべきかを特定する必要があります。
運用モデルの定義には以下を含める必要があります。
-
各チームがそれぞれの役割と責任、そして他のチームとどのようにやり取りするかを理解できるようにするための、実行責任者、説明責任者、相談先、報告先 (RASCI) マトリクス。以下は RASCI マトリクスからの抜粋です。
-
エンドツーエンドのアクティビティを定義し、各アクティビティの責任者を定義するプロセスフローのスイムレーン。例えば、時間外サポートに従事するためのプロセスフローを用意して、誰が連絡を受けるのか、連絡が取れない場合はどのように対応するのか、誰がサポートチケットを記録するのか、ビジネスの重要性はどのように判断するのかを明確にします。もう 1 つの例は、緊急キューイングメッセージです。プロセスフローには、開始の必要性を判断するのは誰か、および決定を下すためにはどのデータを使用すべきかを示す必要があります。
運用モデルは通常、プロジェクトの後半で定義されます。これは、ソリューション設計とユーザージャーニーを完成させてから、プロセスを正確に管理する必要があるためです。ただし、プロセスの早い段階でステークホルダーを集めて、プロジェクトの後半のフェーズに時間を割くことができるようにしておくことをお勧めします。
テンプレートとして使用できる類似ドキュメントの例を組織から収集します。こうすることで、ステークホルダーは文書構造に慣れているため、確認や承認の作業が容易になります。
新しいコンタクトセンターを本番環境に移行する前に、ステークホルダーが運用モデルに同意していることを確認し、本番稼動を決定するための要件にしてください。各チームメンバーは、自分の役割と本番環境でコンタクトセンターを運用するプロセスを理解する必要があります。
サービス導入 (SI)
SI アクティビティは、運用モデルで定義されている変更を実装します。運用モデルの定義は新しいモデルの設計と構築のフェーズであり、SI は運用モデルのデプロイフェーズであると考えてください。
SI チームは多くの場合、組織内の専任チームであり、プロジェクトチームから独立して作業を行います。プロジェクトが本番稼働の承認を受けるには、SI チームの基準とチェックリストに合格する必要があります。例えば、チェックリストには、ユーザー受入テスト (UAT) の結果や、競合イベント (変更のフリーズや他の本番稼動予定イベントなど) がプロジェクトの開始日に発生しないこと、ユーザーが必要なトレーニングを受けていること、運用チームが作業を進める準備ができていることの確認などが含まれます。
SI アクティビティはプロジェクトの最終段階で行わないようにしてください。SI チームはプロジェクトの早い段階で関与させ、設計ドキュメントの配布リストに加えます。早い段階で関与することで、SI チームは、最適な AWS サポートプランの選択
トレーニング
移行を成功させるには、トレーニング資料を作成し、参加者が多いトレーニングセッションを実施することが不可欠です。テクノロジーは完璧に機能していても、ユーザーが電話応答の仕方や日常業務を行う方法を知らなければ、移行は失敗とみなされます。
トレーニングアクティビティには、直接ユーザーのトレーニング、トレーナーのトレーニング、スーパーバイザーのトレーニング、サポートスタッフのトレーニング、システム管理者または製品所有者のトレーニングなどが含まれます。各組織には独自性があるため、ある選択肢が他の選択肢よりも文化的に適している場合もあります。
組織の社内研修スタッフが関与するトレーナー養成アプローチを採用することをお勧めします。スタッフは組織の文化、ユーザーに最適なトレーニング形式やテクニックを理解しています。プロジェクトチームのメンバーは、対象分野の専門家 (SME) の役割を引き受けて、トレーナー養成セッションのソース資料として使用できる技術資料 (ユーザーマニュアル、管理者コンソールマニュアル、スクリーンガイドなど) を提供できます。組織にトレーニングチームがない場合、プロジェクトの SME はスーパーバイザーとリードサポートスタッフを養成して、彼らがコンタクトセンターのユーザーをトレーニングできるようにする必要があります。
また、システム管理者と製品所有者は、インストラクター主導の正式な製品トレーニングコースを受講して、 AWS 環境と Amazon Connect コンソールの理解を深め、製品の機能を使いこなし、効果的なトラブルシューティングを行えるようにすることをお勧めします。
