方向性のあるビジネスケースの作成 - AWS 規範ガイダンス
方向性のあるビジネスケースの範囲の修正フォーカス値ドライバーデータのニーズインフラストラクチャの TCO 比較の構築運用コスト最適化の構築完全な方向性のビジネスケースへの拡張移行とモダナイゼーションプログラムのセットアップの見積もり

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

方向性のあるビジネスケースの作成

ビジネス全体のステークホルダーは、各ステップで変革を進めるために、ビジネスケースを理解し、受け入れる必要があります。

初期段階では、移行プログラムから十分な潜在的な価値をすばやく示すことが重要です。これにより、プログラムの計画と確立に必要なリソースを確保できます。方向性のあるビジネスケースは、早期に収集できる限られたデータで、魅力的なビジネス価値を達成するための合理的な信頼を提供するように設計されています。

プログラムが確立されると、ビジネスケースがさらに発展します。詳細なケースは、より高い精度、プログラム価値のより完全な全体像、計画の優先順位に関するインサイトを提供します。組織が購入する計画されたビジネス成果を定義および定量化し、プログラムガバナンスオフィスがプログラムを運営し、その成果を測定するためのベースラインを設定します。

方向性のあるビジネスケースの範囲の修正

方向性のあるビジネスケースは通常、2～4 週間以内に迅速に組み立てられます。コアチームを確立し、必要に応じて AWS パートナーを関与させ、少なくとも優先順位付けされたアプリケーション評価、ポートフォリオ分析、移行計画の各段階を完了するために、リソースを確保できるように、十分な信頼を生み出す必要があります。

通常、ポートフォリオの移行をサポートする方向性のあるビジネスケースは、次のいずれかとして作成されます。

  • 現状のインフラストラクチャランドスケープと移行後の AWS のサービス アーキテクチャの単純総所有コスト (TCO) の比較。比較は、特定のワークロードボリュームの予想実行率の差を示しています。

  • 移行コストを含む移行と現状維持 を比較するための、純現在価値 (NPV)、投資収益率 (ROI)、ペイバック期間、変更された内部収益率 (MIRR) AWS 、3～5 年間のキャッシュフロー分析を示すビジネスケース。

方向性のあるビジネスケースの範囲は通常、次のいずれかに制限されます。

  • インフラストラクチャテクノロジーコストの比較

  • インフラストラクチャテクノロジーと運用コストの比較

一般的に、ポートフォリオが大きいほど、ケースの開発は少なくなります。これは、結果に大きな影響を与えることなく、より広範な仮定を立てることができるためです。ポートフォリオを小さくすると、変更の影響が大きくなるため、より詳細にする必要があります。

まず、基本インフラストラクチャのコスト比較を構築します。次に、続行する前に、比較が十分に説得力があるかどうかを判断します。通常、400 台を超えるサーバーのポートフォリオは、運用から 3 年以内 AWS、または 5 年以内の 250 台のサーバーでインフラストラクチャのコスト削減のみにプラスのビジネスケースを示しますが、これは異なる場合があります。より小さなポートフォリオでは、より詳細な情報が必要になる場合があります。

逆に、移行範囲の合計が約 5 ワークロードまたは 50 サーバー未満でない限り、回復力の向上やビジネスの俊敏性から派生した値など、この段階で他のビジネス価値のコンポーネントを調べることはあまり有用ではありません。

フォーカス値ドライバー

インフラストラクチャテクノロジーの TCO 比較では、現状のインフラストラクチャコストのモデルと、同等のパフォーマンスと可用性でワークロードを実行するために必要な AWS のサービス 部品表の基本モデルを比較します。多くの最適化を行うことができます。ただし、この段階では、評価が容易で、通常は TCO を約 30% 削減できるため、次のリストに重点が置かれています。

  • コンピューティングの伸縮性 – 8x5 (24% の使用状況）、10x5 (30%)、または 10x6 (36%) を実行している開発サーバーや UAT サーバー、2% を実行しているディザスタリカバリ (DR) サーバーなど、使用量が 100% ではないサーバーを、使用時にのみ課金されるオンデマンドサービスにマッピングします。

  • 削減計画による調達 – 本番稼働用サーバーやその他のサーバーを使用量が多い (36% 超) もの調達を計画し、適切な削減計画でコストを最大 75% 削減します。オプションには、1 年契約と 3 年契約があり、割引率を高めるために前払いレベルが異なります。

  • ゾンビの削除 — CPU 使用率が 2% 未満のサーバーのうち、不要になったことを確認できるサーバーを特定し、コスト分析から削除します。

  • コンピューティングの適正サイズ — CPU とメモリの使用率の時系列データを使用して、サーバーごとに必要なコンピューティング能力とメモリを評価します。次に、適合する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを選択します。

  • リレーショナルデータベース管理システム (RDBMS) ライセンスの適正サイズ設定 – データベースサーバーでコンピューティングの適正サイズ設定を行った後、RDBMS ライセンスのニーズを再評価し、 から自分のライセンス (BYOL) と調達ライセンスを比較し AWS、Amazon Relational Database Service (Amazon RDS) の可能性を調べて削減額を増やします。

  • ストレージ – 必要なストレージボリュームの合計を適切なサイズに設定し、ポートフォリオ全体で 1 秒あたりの入出力オペレーション (IOPS) のニーズを特定します。SLA SLAs とコストが異なるオブジェクトストレージに移動できる量を決定します。

データのニーズ

「初期評価データ要件を理解する」の表は、方向性のあるビジネスケースの各部分を構築するために必要なデータと、必須かオプションかを示しています。

ケースを構築するには、初期計画データとコストデータのインフラストラクチャサブセットが必要です。含めるインフラストラクチャを特定する方法は、ビジネス目標によって異なります。

  • プログラムの目的は、特定のアプリケーションを移行してモダナイズすることである場合は、共有されるインフラストラクチャを考慮して、アプリケーションが必要とするものに基づいてインフラストラクチャポートフォリオを構築します。

  • リースの有効期限が切れるデータセンターから移行するなど、プログラムの目的がインフラストラクチャ中心である場合、インフラストラクチャの TCO 比較にアプリケーションマッピングは必要ありません。

オプションとしてマークされたデータ (サーバーの CPU やメモリのピーク使用率など) は通常、標準のベンチマーク値に置き換えることができます。これについては、 AWS パートナーまたは AWS プロフェッショナルサービスにお問い合わせください。または、ポートフォリオの一部で利用可能なデータポイント (ハイパーバイザーによって収集されたデータなど) から値を推定することもできます。ポートフォリオが大きいほど、より正確です。

インフラストラクチャの TCO 比較の構築

インフラストラクチャの TCO 比較を構築するには、ツールが不可欠です。AWS プロフェッショナルサービスまたは AWS パートナーは、特により広範な移行プロセスを支援するために、あらゆる種類の方向性のあるケースを支援できます。

以下の操作に使用できるツールがあります。

  • インベントリデータを収集します。

  • 使用率データを収集します。

  • インフラストラクチャのコストベンチマークデータをそのまま正確に提供します。

  • ゾンビを特定して削除します。

  • 適切なサイズ評価を行います。

  • 購入オプションを推奨します。

  • ソフトウェアライセンスオプションを比較します。

  • シンプルなグラフィカルなキャッシュフロー分析を生成します。

からの移行評価者 AWS は 1 つのオプションです。これらの機能はすべて、無料のマネージドサービスとして提供されます。Migration Evaluator は、 AWS アカウントマネージャーまたは AWS Migration Competency Partner を通じて、またはオンラインでリクエストを送信することでリクエストできます。Migration Evaluator は、インフラストラクチャテクノロジーの TCO 比較を迅速に生成するためのポイントソリューションとして特別に設計されています。

主な利点：

  • 無料

  • ツールベースの検出が制限されているインベントリデータのエージェントレス検出または手動設定

  • デプロイ、設定、データ収集、ベースケースの構築、または方向性のあるビジネスケースを支援するための専用サポート

  • SaaS オペレーションの利便性はありますが、顧客ネットワーク内でデータ収集を完全に実行して、分析エンジンにロードする前にスクラブをサポートできます。

  • Microsoft ライセンスの適切なサイズ設定に対する強力なサポート

  • 完全なデータエクスポート機能

主な制限事項：

  • x86 アーキテクチャサーバー (Windows および Linux) のみを評価

  • ベンチマークをそのままコストデータとして設定またはキャリブレーションするためのオプションが限られています

  • モデリングオペレーションのコスト最適化はサポートされていません

  • 移行コストモデリングのサポートなし

  • TCO 比較以外のビジネスケースの構築を直接サポートしない

アプリケーションスタックや相互依存関係検出などのポートフォリオ検出および分析機能に商用検出ツールを使用することにした場合、通常、インフラストラクチャの TCO 比較も提供されます。ポートフォリオの検出と評価のためのツールの使用に関するガイダンスについては、「検出ツールの必要性の評価」を参照してください。市場をリードするツールの主な機能を確認して比較するには、「検出、計画、推奨事項の移行ツール」を参照してください。

運用コスト最適化の構築

IT 運用の生産性向上は、多くの場合、移行にとって大きな価値をもたらします。アマゾン ウェブ サービスでビジネス価値を生み出すためのビジネスと組織の変革を促進する国際データ公社 (IDC) のホワイトペーパーによると、移行後 AWS、IT 運用スタッフの生産性は平均 62% 向上します。 https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770ただし、これらの利点を方向性のあるケースにサイジングして含めるには、2 つの課題があります。

まず、生産性の向上の全範囲を評価するには、広範なデータ収集が必要であり、詳細なビジネスケースに適しています。この課題は、単純なベンチマークデータで評価およびサイズ設定がより簡単だが、それでも大きな利点を示すいくつかの要素に焦点を当てることで解決できます。

2 つ目は、コスト削減のソースとして生産性を重視すると、主要な顧客のステークホルダーとプログラムメンバーの間に懸念と否定が生じる可能性があります。メリットがどのように実現されるか、またそれが影響を受ける人々にとってどのような意味を持つかを明確にしてください。このような問題は、チームの役割を強化するだけであることを明確にすることで回避できます。

  • 移行プログラムには、コードオートメーションとしてインフラストラクチャを構築する DevSecOps チームへの参加や、チームの成長を促進するオートメーションのテストなど、内部運用スタッフを開発して新しい役割に移行するトラックが含まれています。

  • メリットは、オペレーションのアウトソーシング契約の範囲変更とサイズ変更によって実現できるため、社内スタッフが価値の高いアクティビティに集中できるようになります。

考慮すべきオペレーション変換に基づいて、このビジネスケース要素を構築するアプローチ：

  • 既存の社内運用チームがある場合は、チームメンバーのスキルを向上させ、期待される生産性の向上を示します。

  • または、現在の運用ソリューションから AWS Managed Services (AMS) または AWS パートナーが提供する代替マネージドサービスに移行します。

最初の変換では、ケースに含めることができる生産性の向上について控えめに財務上の見積りを取得するには、以下をお勧めします。

  1. 特にサーバー管理オペレーションの生産性に焦点を当てます。オペレーションの労力の大部分を占める傾向があり、より簡単に評価でき、後でより簡単に検証できます。

  2. 各フルタイム同等の (FTE) 従業員が管理できるサーバー数のベンチマークに基づいて、必要な人員配置を計算します。オンプレミスでは、この数は約 150 サーバーです。 AWS上のサーバー数は約 400 です。

  3. これらのメトリクスを EC2 インスタンスの数と比較したオンプレミスサーバーの数に適用します。

  4. 節約した時間を運用チーム全体のブレンドコスト率で乗算します。

その後、結果をどちらの方法でも確認するには、結果を次の表に示すロール (IDC ホワイトペーパー Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services から取得したデータ) による平均生産性の向上を大幅に上回らないことを確認します。

ロール

効率の向上

IT インフラストラクチャ管理

62%

IT サポート

59%

アプリケーション管理

43%

データベース管理

19%

アプリケーション開発

25%

2 番目の変換では、対象範囲内のポートフォリオの現在の総運用コストとサポートコストを、考慮されるマネージドサービスのコストと直接比較することで、運用コストの削減を追加できます。

マネージドサービスのコストを取得するには、提案された部品 AWS 表、サービスレベルの選択 (Plus または Premium)、および AMS パッケージ (AMS Accelerate または AMS Advanced) を AWS アカウントマネージャーまたはAWS Managed Services パートナーに提供します。これにより、変換されたソリューションの :AWS のサービス コンポーネントのマネージドサービスの合計コストが提供されます。同様に、独自のパラメータに基づいて独自のマネージドサービスパッケージを提供する AWS パートナーから料金を取得できます。

完全な方向性のビジネスケースへの拡張

一般的に、完全な方向性のビジネスケースを組み立てるには、IT 生産性要素の有無にかかわらず TCO 比較を構築し、すべての移行とモダナイゼーションのコストを見積もります。次に、migrate-and-modernizeのシナリオのペアとt-migrate-and-modernizeシナリオのペアをカバーするキャッシュフローを作成します。

最も基本的なケースは、移行t-migrate-and-modernizeするシナリオが現在の状況であり、migrate-and-modernizeシナリオには次の特性がある 1 組のシナリオの準備です。

  • トランザクションボリューム、コンピューティング、またはネットワーク容量の増加や縮小がない

  • ストレージ要件の着実な少量の増加

  • 既存のシステム機能と一致するQuality-of-service機能 (可用性、耐久性、スループット、パフォーマンスなど）

これは、非常に小さなポートフォリオを除くすべてのポートフォリオで、方向性のあるケースをうまく構築する目的に合致します。これは、先に進むための義務を得るために十分な価値を迅速に示します。

小規模なポートフォリオでは、migrate-and-modernizeのペアを追加し、クラウド移行の価値の増大に関する他の側面を示すシナリオt-migrate-and-modernize方が有益です。次に例を示します。

  • 中程度と大容量の増大要件が、その増大が予想されるワークロード間で混在する

  • 高可用性、DR、耐障害性など、回復力の強化を含める

  • エッジコンピューティング、コンテンツ配信ネットワーク (CDN)、マルチリージョンデータベースレプリケーションでグローバルパフォーマンスが向上しました。

  • プログラムのビジネス上の優先事項となったその他の特定のサービス品質の向上

これらのシナリオでは、現在のクラウド以外のインフラストラクチャアーキテクチャを新しい仕様に合わせてアップグレードした場合のコストとキャッシュフローへの影響が正確に推定されていることを確認してください。この見積りを取得する最も直接的な方法は、特に移行コンピテンシーを持つ AWS コンサルティングパートナーで、migrate-and-modernizeの両方のシナリオとt-migrate-and-modernizeの両方をサポートできる場合、システムインテグレーターに見積りをリクエストすることです。

シナリオのペアごとに、以下で構成されるケースを組み立てます。

  • のコストはt-migrate-and-modernizeシナリオです。最も基本的な場合、これには以下が含まれます。

    • 現在のインフラストラクチャ設定のビジネスケース期間における総所有コスト

    • コンピューティング、ストレージ、ネットワークトラフィックの消費量の定期的な増加

  • migrate-and-modernizeのコスト。以下を含むシナリオ。

    • 詳細な検出、移行計画、詳細なビジネスケース開発、コアチームの確立とスキルの向上、まだ導入されていない場合のランディングゾーンの確立、移行されたワークロードのセキュリティ管理と運用の統合の確立など、プログラムのセットアップ

    • ワークロードの移行とモダナイゼーションのコスト

    • ネットワーク接続、 AWS Snowball Edge や などのデータ移行サービスAWS DataSync、移行プロセス自体に必要なアーキテクチャの AWS ユーティリティコスト (テストなど) を含む移行インフラストラクチャのコスト

    • ウェーブが本番稼働するにつれて移行中の AWS ユーティリティコストが増加し、既存のインフラストラクチャコストが AWS ベースのサービスに置き換えられ、廃止されるにつれて増加します。

  • ストランドアセットの廃止コストと償却

移行とモダナイゼーションプログラムのセットアップの見積もり

プログラムを成功させるためにセットアップするには、ベースライン機能と詳細計画を構築するための一連の基本的なアクティビティを、以前に実行していない場合に実行する必要がある場合があります。これらの基本的なアクティビティには以下が含まれます。

  1. ポートフォリオ分析と移行計画セクションで説明されているように、詳細なポートフォリオ検出、移行計画、詳細なビジネスケース開発を実行するとともに、使用した検出ツールのコストを文書化します。

  2. クラウドビジネスと技術のコアチームを確立し、トレーニングと雇用を通じて社内スキルを開発します。トレーニングが必要な IT 組織のメンバーを特定し、各メンバーにトレーニング予算を割り当てます。

  3. ランディングゾーンを確立し、必要なコスト、運用、セキュリティガバナンス機能をサポートするように設定します。

AWS コンサルティングパートナーは、項目 1 と 3 の見積もりの提供に役立ちます。

移行とモダナイゼーションのコストの見積もり

方向性のあるビジネスケースの目標を達成し、次のフェーズに進むのに十分な商業的可能性を示すには、移行とモダナイゼーションのコスト見積もりをできるだけ基本的なものにします。

そのためには、次の移行戦略に該当するアプリケーションに焦点を当てて、方向性のあるビジネスケースを準備することをお勧めします。

  • リタイア

  • Retain

  • リロケート

  • リホスト

  • リプラットフォーム

  • 再購入

通常、ワークロードの約 70% はリホスト、再配置、またはリプラットフォームでき、さらに 5% はリタイアできます。通常、移行戦略によるアプリケーションの評価は、コスト削減ケースの中核をなします。

リファクタリングまたは再設計のコストの見積もりは複雑になる場合があります。方向性のあるビジネスケースを準備するために与えられた期間内にこれを試すことは現実的ではありません。前述の「移行の R タイプを決定する」で説明したように、移行とモダナイゼーションの最初のフェーズでは、リホスト、再配置、またはリプラットフォーム戦略の使用を検討してください。これらの R 戦略は、初期のペイバックを加速し、実装リスクを軽減し、短期的にビジネスケースを改善する可能性があります。また、アプリケーションチームは AWS 、環境内で実行されているアプリケーションをモダナイズする方が、そうでないアプリケーションよりもはるかに簡単です。詳細なビジネスケースの準備が整うと、リファクタリング (再設計) 固有のアプリケーションの見積もりが最適に追加されます。

戦略による移行の労力の見積もり

移行はそれぞれ異なります。予算や計画をコミットする前に、社内のアプリケーションチーム、 AWS プロフェッショナルサービス、パートナー AWS 組織など、プロジェクトを担当するチームからの移行アクティビティのワークロード見積もりをシードします。

方向性のケースを構築するために、次の表にさまざまな処理の労力範囲を示します。これらの範囲は、medium-to-largeのポートフォリオが移行中であり、移行チームがトレーニングされ、経験があることを前提としています。小規模なポートフォリオの場合は、方向性のあるケースであっても、移行を担当するチームに見積りを準備することをお勧めします。

移行戦略 見積りプロセス [Elements] (要素) 人時 人時
Retain Do nothing, with no cost, no benefits, and no reduction in technology debt.

–

–

–
Retire Estimate decommissioning the hardware equipment used, if any.

–

–

–
Relocate Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns.

–

–

–
Rehost Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as AWS Application Migration Service. Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes. Effort per app per server Migration HA/DR test
Low 10–14 3–5
Medium 16–24 4–6
High 26–38 8–12
Replatform For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as AWS Schema Conversion Tool and AWS Database Migration Service, and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement. Effort per app per server Version up Technology change
Low Add 1–3 Add 10–15
Medium Add 2–5 Add 20–30
High Add 4–8 Add 40–60
Repurchase Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning.

–

–

–

移行インフラストラクチャのコストの見積もり

移行中に使用するインフラストラクチャの見積もりを含めます。通常、これらの見積もりは以下で構成されます。

  • 現在の環境から へのワークロードとデータ移行のための接続とデータ交換サービスの予算 AWS

  • 移行、テスト、カットオーバープロセス中に移行されたワークロードをホストするために必要な AWS のサービス （特にコンピューティングとストレージ) の予算

  • 各移行ウェーブの完了に伴う AWS ユーティリティコストの急増

  • 移行されたワークロードを実行しない既存のインフラストラクチャの廃止コスト

データ交換については、合計データボリュームを調べ、ネットワークの使用の実現可能性を評価します。移行後に運用上の使用のために AWS Direct Connect または AWS VPNから WAN 上のポイント AWS へのリンクを事前にプロビジョニングしている場合は、そのリソースをサービスクォータまで使用できます。

ネットワーク容量が不十分な場合、仮想プライベートネットワーク (VPN) によるインターネット帯域幅の短期的な増加は、多くの場合、費用対効果の高いソリューションです。そうでない場合、 AWS Snowball Edgeや などの AWS メディア交換デバイスは、ほとんどの でAWS Snowball Edgeソリューションを提供します AWS リージョン。また、非常に大量のデータ移行の場合は、 の予算を含めることを検討してください。これにより、信頼性が向上しAWS DataSync、使用するメディアに関係なく転送が高速化されます。

AWS サービスの拡大と既存のインフラストラクチャの縮小をモデル化することは、ビジネスケースのキャッシュフロー分析要素にとって重要です。この段階では、いつコストが発生するかを正確に判断するためのウェーブプランがある可能性は低くなります。次の構成を推奨します。

  • のコストを移行中も一定の割合 AWS で引き上げます。

  • 同じ期間にわたって一定の割合で廃止する予定の既存のインフラストラクチャのコストを引き下げる。

既存のインフラストラクチャが縮小する 1～2 か月前に AWS コストが上昇する。これにより、各ウェーブの移行を実行するために 1 か月の AWS ユーティリティ使用量が提供されます。これには、テストにかかる時間と、置き換えられたインフラストラクチャでコストが発生するのを停止するために必要な廃止作業を完了する追加の時間が含まれます。

廃止コストの見積もり

再デプロイできない機器の廃止や、法的かつ環境に優しく廃棄すると、少額のコストが発生する可能性があります。ただし、方向性のあるビジネスケースでは、通常、重要な可能性がある合計は、置き換えられたアセットの残りの書籍価値を償却するコストです。

方向性のあるビジネスケースでは、以下を実行することをお勧めします。

  • アセットリストを確認します。

  • 廃止されるものを特定します。

  • ライトオフを減らすには、リストの新しいデバイスを使用して、より完全に廃止された古いアセットを置き換えることができるように、デバイスを切り替えられる機会を調べます。

  • その時点で廃止されるアセットの将来の書籍価値を評価します。

  • これを廃止の移行コストとして含めます。

完全な方向性のビジネスケースの組み立てと調整

シナリオのペアごとにコストの完全なセットを準備したら、それぞれに割引されたキャッシュフローステートメントを作成し、グラフ化します。ハードウェアの更新サイクルと同じ期間に方向性のあるビジネスケースを構築することをお勧めします。これは通常、サーバー、ストレージ、ネットワークデバイスの場合は 5 年間です。ハードウェアの更新サイクルと同じ期間を使用する場合、1 回のみの更新のコストは、各シナリオの現状有姿のコストに含まれます。

次に、プログラムの次のフェーズに移行するための承認を得るために必要な主要な財務メトリクスを計算します。通常、以下が含まれます。

  • 評価されたコスト削減と生産性の向上の絶対値を測定する正味現在値 (NPV)

  • リターンが十分に高速であることを確認するための月単位のペイバック期間

  • プロセスが期間にわたって十分なコストを奪っているかどうかを確認するための最終実行レート比較

  • 組織が優先する可能性のある資本に対する他の需要と比較して、プログラムの相対的な財務パフォーマンスを評価するための投資収益率 (ROI) と変更された投資収益率 (MIRR)

次の例のように、ケースの最初の反復を使用して、予想される財務パフォーマンスが微調整を行う必要があることを意味するかどうかを判断します。

  • ペイバックが遅すぎる場合は、次のような移行のコストを高速化して削減するためのオプションを検討してください。

    • AWS パートナーまたは AWS プロフェッショナルサービスを使用して利用可能なリソースを拡張し、より基本的なパターンでワークロードの移行をさらに並列化します。

    • VMware で実行されているワークロードの場合、少なくとも初期フェーズでは、再配置戦略とリホストまたはリプラットフォーム戦略を比較します。再配置戦略を使用すると、移行コストを削減し、移行速度を向上させることができます。

    • 技術的に可能な場合は、より複雑なリプラットフォームまたはリファクタリング (リアーキテクト) 戦略を必要とするワークロードを、最初のビジネスケースの範囲外の将来のフェーズにプッシュします。

  • ROI と MIRR が低すぎる場合は、次の点を考慮してください。

    • 検討しているシナリオは保守的すぎますか？ 最も可能性の高い容量の増加と伸縮性のニーズを反映したシナリオはありますか？ 目標内のサービス品質の向上を含むコストを比較するシナリオはありますか？

    • 第 1 フェーズで移行するアプリケーションポートフォリオの範囲を絞り込んで、現在の使用率が低いワークロードや、ディザスタリカバリ (DR) のニーズが高いワークロードなど、より強力なリターンをもたらすワークロードに集中できますか？

    • アプリケーションポートフォリオの範囲を絞り込んで、最初に、あまり商用ではない特定のワークロードを除外できますか？ 例えば、パブリッククラウドインフラストラクチャへのデプロイ条件が異なるため、サードパーティーのソフトウェアライセンスのコストが高くなるワークロードを延期できますか？

  • 最終的な実行レート比較が想定ターゲットを満たさない場合は、以下を調べます。

    • まず、他のメトリクスが期待を満たしていることを確認します。方向性のあるビジネスケースは、主に移行準備の次の段階を開始することを正当化する十分な財務機会があることを示すためのものです。

    • 移行の初期フェーズ AWS 後も のコストパフォーマンスを継続的に改善する機会のリストを特定します。

詳細なビジネスケースを準備する際には、機会のリストの評価を含めます。さらに、ケースの継続的なメンテナンスと、移行完了後のmonth-to-monthのコスト最適化プロセスに機会評価を含めます。