翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 意思決定プロセス
<a name="decision-making-processes"></a>

以下の手順を使用して、オンプレミスのAvayaコンタクトセンターから Amazon Lex および Amazon Connect Customer に移行するための戦略を定義します。
+ [ステップ 1: ビジネス目標とスケジュールを明確にする](#step-1)
+ [ステップ 2: 段階的アプローチをとるか完全移行するかを選択する](#step-2)
+ [ステップ 3: 移行戦略を選択する](#step-3)
+ [ステップ 4: アーキテクチャを選択する](#step-4)

## ステップ 1: ビジネス目標とスケジュールを明確にする
<a name="step-1"></a>

移行の意思決定プロセスにおける最初のステップです。プロジェクトの目標が、セルフサービスを増やして Amazon Lex を IVR にのみ使用することである場合は、Avayaと Amazon Lex 間の通話転送方法の戦略を策定する必要があります。既存のオンプレミスシステムの制約を理解すると、効率的なアーキテクチャを設計できます。以下はビジネス目標の概略と、その期待される達成スケジュールの例です。
+ 3 か月以内に、各ビジネスユニットの Avaya IVR を段階的に Amazon Lex に移行します。
+ 1 年以内に、Avayaオンプレミスシステムから Amazon Connect Customer と Amazon Lex に完全に移行します。

## ステップ 2: 段階的アプローチをとるか完全移行するかを選択する
<a name="step-2"></a>

コンタクトセンターシステムの移行を検討する際は、次の 2 つのアプローチが考えられます。
+ **段階的アプローチ – **このアプローチでは一度にすべて移行するのではなく、特定のコンポーネントまたは機能を段階的かつ戦略的に移動します。一度に 1 つの IVR ビジネス機能を移行することで、よりきめ細かく管理して、混乱を最小限に抑えることができます。このアプローチでは、段階を進めるにつれてテスト、学習、調整ができます。複雑なシステムを持つ組織やリスクを最小限に抑える必要のある組織で、通常推奨されるオプションです。
+ **完全移行 –**** **このアプローチでは、移行を段階ごとに分割せず、すべてのコンタクトセンターシステムを同時かつ完全に切り替えて移行します。このアプローチは迅速ですが、課題も伴います。そのため、綿密な計画と準備が必要です。移行計画に自信があり、より迅速に移行する必要がある場合は、こちらのアプローチを採用するとよいでしょう。

アプローチを決定する際は、ビジネスオペレーションの規模、複雑さ、特定のニーズの評価が不可欠です。重要なのは、中断を最小限に抑えることと、新しいシステムに確実かつスムーズに移行することのバランスを取ることです。

## ステップ 3: 移行戦略を選択する
<a name="step-3"></a>

従来のオンプレミスコンタクトセンターは通常、デュアルトーンマルチ周波数 (DTMF) アプローチ、または音声テキスト変換のアプローチに基づいて構築されています。Amazon Lex でオンプレミスのエクスペリエンスを再現することは、特にコールフローが非常に複雑な場合は推奨されません。代わりに、Amazon Lex の AI 機能を使用してエクスペリエンスの向上に取り組むことができます。ただし、プロジェクトの目標がクラウドへの移行であり、既存のコールフローがごく簡単である場合は、リホストしてから将来的にエクスペリエンスをモダナイズする選択もあります。

## ステップ 4: アーキテクチャを選択する
<a name="step-4"></a>

移行プロジェクトの目標に応じて、このガイドの「[オンプレミスのAvayaコンタクトセンターを に移行するためのアーキテクチャオプション AWS](architecture-options.md)」セクションで解説している利用可能なアプローチのリストから選択します。