View a markdown version of this page

方向性のあるビジネスケースの作成 - AWS 規範ガイダンス

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

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

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

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

プログラムが確立されると、ビジネスケースがさらに発展します。詳細なケースにより、精度が向上し、プログラムの価値をより完全に把握し、計画の優先順位を把握できます。組織が購入する計画されたビジネス成果を定義して定量化し、プログラムガバナンスオフィスがプログラムを運営し、その成果を測定するためのベースラインを設定します。

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

方向性のあるビジネスケースは通常、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% ではないサーバーを、使用時にのみ課金されるオンデマンドサービスにマッピングします。

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

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

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

  • リレーショナルデータベース管理システム (RDBMS) ライセンスの適切なサイズ設定 – データベースサーバーのコンピューティングの適切なサイズ設定後に RDBMS ライセンスのニーズを再評価し、Bring Your Own License (BYOL) と Procuring license from を比較し 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 つの課題があります。

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

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

  • 移行プログラムには、内部運用スタッフを開発し、新しい役割に移行するためのトラックが含まれています。例えば、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シナリオには次の特性があります。

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

  • ストレージ要件の低ボリュームの着実な増加

  • 既存のシステム機能に一致する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 の見積りを提供できます。 

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

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

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

  • リタイア

  • 保持する

  • リロケート

  • リホスト

  • リプラットフォーム

  • 再購入

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

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

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

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

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

移行戦略

見積りプロセス

[Elements] (要素)

人時

人時

保持する

何もせず、コストもメリットもテクノロジーの負債も削減しません。

リタイア

使用されているハードウェア機器がある場合は、廃止を見積もります。

リロケート

VMware ツールを使用して VMware 内のワークロードのコピーを推定します。これには、データのコピー、検証のための煙テスト、ハードウェアの廃止が含まれます。VMs を再配置する労力は、通常、複雑さの低いリホストパターンの場合よりも小さくなります。

リホスト

本番サーバーに適した場合は、イメージコピー、煙テスト、高可用性 (HA) およびディザスタリカバリ (DR) テスト、ハードウェアの廃止を使用して、ワークロードとデータのコピーを推定します。ベストプラクティスは、 などのツールを使用することですAWS Transform MGN。データベースまたは他のインフラストラクチャソフトウェアが実行されているかどうか、データベースの複雑さ、クラスター化されているかどうか、統合の複雑さ、データボリュームなどの要因に基づいて、ワークロードを低、中、高の複雑さに分割します。

サーバーあたりのアプリケーションあたりの労力

移行

HA/DR テスト

10~14

3~5

16~24

4~6

26~38

8~12

リプラットフォーム

オペレーティングシステムまたは RDBMS バージョンへのアップグレードを含むリプラットフォーム移行の場合は、リホストの見積もりを取得し、新しいプラットフォームで再構築と煙テストを実行する時間を追加します。プラットフォームのテクノロジーの変更がリプラットフォームに含まれている場合は、 AWS Schema Conversion Toolや などの変換ツールを使用するための追加の時間を見積もりAWS Database Migration Service、より完全なアプリケーションテストを行います。テクノロジーを変更する例として、独自の商用データベースからオープンソースの置き換えへの移行が挙げられます。

サーバーあたりのアプリケーションあたりの労力

バージョンアップ

テクノロジーの変更

1~3 を追加する

10~15 の追加

2~5 を追加する

20~30 の追加

4~8 の追加

40~60 を追加する

再購入

データ抽出、変換、新しく購入した SaaS サービスへのアップロード、およびハードウェアの廃止を推定します。

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

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

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

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

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

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

データ交換については、合計データボリュームを調べ、ネットワークの使用の実現可能性を評価します。移行後に運用上の使用のために AWS Direct Connect または Site-to-Site 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コスト最適化プロセスに機会評価を含めます。