詳細なビジネスケース

この段階では、ビジネスケースの範囲を検証して拡張し、変換プログラムをサポートするためにより詳細なレベルを提供することをお勧めします。すぐに組み立てられる最初の方向性のあるビジネスケースは、基本的なステップと次のレベルの詳細な計画に投資するのに十分な信頼性を提供するように設計されています。

詳細なビジネスケースを作成すると、次の方法でこの計画プロセスがサポートされます。

• 移行およびモダナイズすべき内容、選択するオプション、作業を段階的に優先順位付けする方法に関する意思決定に役立つ財務分析を提供する

• 詳細を再検討して、元の方向性財務ケースを検証、改良、開発します。

  • インフラストラクチャのコスト削減の可能性

  • 社内の IT 生産性と外部委託運用の効率性

  • プログラムのセットアップ、移行、モダナイゼーションに必要な投資の見積もり

• 移行がもたらすさらなる価値の推進要因を追跡するプロセスの特定、スケールの推定、設定

詳細なビジネスケースでは、以下を確立します。

• 少なくとも移行の第 1 フェーズを実装するためのマンデートと投資を確保する目標ベース

• プログラムのベースラインの最小財務パフォーマンスの期待値

• さまざまな移行設計と優先順位付けの決定が行われる財務基盤を明確にし、プログラムの過程で状況や人が変化したときに、新しいリーダーシップが情報に基づいた選択を行うことができます。

• ワークロードの移行と運用の開始時に最初の使用状況データが利用可能になった後に調査するコスト最適化の増分領域に関するインサイト

• クラウドトランスフォーメーションがビジネスにもたらす価値を、回復力と俊敏性の向上から推定します。

• 回復力と俊敏性の向上による財務収益を見積もるために使用される、関連する KPIs、メトリクス、および仮定。これにより、プログラムからの主なメリットの実現を促進するためのベースラインが形成されます。

ケースに必要なシナリオを決定する

詳細なビジネスケースを構築する場合、通常、ビジネスケースが使用されるさまざまな目的をサポートする複数のシナリオを開発する必要があります。

最小変更シナリオ – 最低限の財務パフォーマンスの期待値を評価するには、ステータスクォーに対する最低限の変更を想定したシナリオを準備します。このシナリオは、最悪のシナリオとして、移行に投資する義務を取得する場合に役立ちます。このシナリオでは、可用性や回復力など、他のquality-of-serviceのニーズに対して予想される最小の容量増加度と最小の変更をモデル化します。最小の変更は、現在の運用モデルにとって最小のコストと最小のリソース非効率をもたらします。

最も可能性の高いシナリオ – プログラム戦略と優先順位付けの決定を通知するには、ビジネスが期待することを反映するシナリオを準備します。このシナリオには、ピーク時の使用率の増加または減少の可能性と、ビジネスからの高いレベルのサービス品質 (特に可用性と回復力) の需要を満たすためのアップグレードコストを含める必要があります。

その他の特定のシナリオ – ビジネスケースに大きな影響を与える可能性のある仮定をまだ作成する必要がある場合は、仮定が当てはまる場合とそうでない場合の両方のシナリオを作成します。ただし、これらの代替シナリオの数は絶対最小にしておくことをお勧めします。合計で 3～4 個を超えるシナリオを作成すると、進行が遅くなり、コストが高くなり、混乱し、維持が困難になります。可能な限り、実験を行い、より大きな仮定を削除してください。

インフラストラクチャと移行コストモデルを検証して絞り込む

ポートフォリオ分析を完了し、ターゲットの設計とサイジングの準備が完了したら AWS のサービス、シナリオ AWS ごとに の現在の運用モデル (COM) と将来の運用モデル (FOM) の運用コストの見積もりを絞り込みます。通常、以下の見積もりを絞り込む必要があります。

• ハイパーバイザーホストサーバー、ベアメタルサーバー、ストレージ、ネットワークデバイス、セキュリティアプライアンスハードウェアの更新、インストール、メンテナンスの COM インフラストラクチャコスト。シナリオに必要な容量の実際の料金と割引レベルで計算します。

• スペース、冷却、電力、ラック、無停電電源 (UPS)、ケーブル、物理セキュリティシステム、成長に合わせてサイズ設定され、容量を満たすように指定された COM データセンターとコロケーションされた施設のコスト、シナリオの高可用性とディザスタリカバリ (DR) レベルが含まれます。

• シナリオの接続、帯域幅、スループット、レイテンシーのニーズに関する契約料金を使用して計算された、WAN リンク、コンテンツ配信ネットワーク、仮想プライベートネットワーク (VPNs) のコストを含む COM ネットワークサービスのコスト。

• 既存の契約に基づく COM アプリケーションおよびインフラストラクチャソフトウェアのコスト。シナリオの使用量の増加または削減を提供します。

• 洗練されたサービスアーキテクチャ、インスタンスサイズ、優先料金モデル、予想される使用量、使用状況の変動性に基づく、必要に応じて技術サポートやマネージドサービスを含む FOM AWS ユーティリティコスト。

• 最終的なアプリケーション設計、アプリケーションを実行するインフラストラクチャの設定、時間の経過に伴う増加、ライセンスの移管可能性ルールに基づく FOM アプリケーションライセンス。

• FOM 移行とモダナイゼーションのコスト見積もり。シナリオのベースライン移行ウェーブプランを反映するように改良され、特にリプラットフォーム、再購入、またはリファクタリングされるワークロードごとにコストを提供するように詳述されています。

• アセットの償却コストと契約早期終了コストの見積もり、ベースライン移行ウェーブプランの廃止タイミングを反映するように改訂された FOM 廃止コスト、償却を最小限に抑えるために再利用できるアセットと切り替えることができるアセットの検証、物理アセットとメディアの廃棄コストなど。

• 移行の並列実行コストは、各移行カットオーバーと既存の各サービス廃止のタイミングを反映するように調整されています。

IT 生産性と IT 運用を改良し、効率バリューモデルをサポートする

方向性のあるビジネスケースと同様に、IT 運用とサポートに関する価値モデルを改良および開発するための主要なアプローチは 2 つあります。選択するアプローチは、COM が社内で管理されているか、請負業者または外部委託サービスで管理されているかによって異なります。

社内チームの生産性向上

IT 運用とサポートが社内で管理されている場合、ビジネスケースの焦点は以下です。

• 移行と対象範囲に含まれる運用自動化による生産性の向上を特定して定量化する

• 社内チームのために解放された時間が、他の通常価値の高いアクティビティに簡単かつ生産的に適用できることを検証し、チームに進歩の機会とより大きな報酬を与え、組織により大きな価値をもたらす

チーム内の各ロールの各メンバーがさまざまな通常のアクティビティに費やす時間を評価し、さまざまなアクティビティのワークロードの予想される削減に関するガイダンスを提供します。

次の表は、IT オペレーションの大部分を消費し、チーム内のさまざまなロールの労力をサポートするタスクのアクティビティ別のワークロード削減の一般的なレベルに関する初期ガイダンスを示しています。この表には、生産性の実現方法の説明が含まれています。

注記

リストされているアクティビティは通常、複数の異なるロールのチームメンバーによって実行されるため、各タスクの生産性の節約は、チーム内のロールの完全なセット全体で評価する必要があります。例えば、インフラストラクチャタワー (コンピューティング、ストレージ、ネットワークなど) 別に編成された IT 運用チームでは、設備投資の計画と予算編成が各タワーのタワーリードに共通している可能性があります。

運用およびサポートアクティビティ	削減額	生産性ドライバー
インフラストラクチャ設計	Medium	設計が簡素化され、考慮するパラメータが少なくなります。
設備投資の計画と予算編成	高	OPEX 中心の Elastic サービスは、実質的にすべての予算と計画の問題を排除します。
購入	高	調達は、 が確立されると大幅に簡素化 AWS アカウント されます。
キャパシティプランニング	中～非常に高い	ネットワーキングとコンピューティングキャパシティ管理のワークロードは通常すべて排除され、ストレージでは大幅に簡素化されます。
チューニング	非常に高い	インスタンスのサイズはいつでも変更できるため、マネージドサービスではチューニングは不要で、他のサービスではほとんど必要ありません。
ハードウェア障害の管理	非常に高い	クラウドでのハードウェア処理のすべての側面は、 によって透過的に処理されます AWS。
サーバーの可用性と通信のモニタリング	高	ツールのサポートと自動化により、 AWS モニタリングと通信は広範囲に簡素化されます。
セキュリティ管理	Medium	ワークロードは、 AWS セキュリティ機能や、 AWS クラウド ハードウェア、ソフトウェア、ネットワーク、施設のセキュリティ責任の AWS 所有者によって大幅に削減されます。
ネットワークとストレージのアップグレード、メンテナンス、パッチ。	非常に高い	クラウドでのネットワークとストレージのメンテナンスのすべての側面は、 によって透過的に処理されます AWS。
ラックとスタッキング — ハードウェアロジスティクス	非常に高い	クラウドでのハードウェア管理のすべての側面は、 によって透過的に処理されます AWS。
バックアップ	Medium	バックアップは、 AWS ツール、柔軟なストレージシステム、自動化によって大幅に簡素化されます。
マネージドサービス (Amazon S3、Amazon RDS AWS Lambda、 など AWS Fargate）	非常に高い	マネージドサービスは、 によって完全に管理されている環境で実行されるため AWS、メンテナンス、パッチ適用、モニタリング、プロビジョニングの管理アクティビティは必要ありません。
デバイスとサービスのセットアップとコミッショニング	非常に高い	に移行したエステートのハードウェアセットアップのアクティビティは通常、VPN VPNs または AWS データセンター AWS Direct Connect への接続を確立するための WAN 接続デバイスを除き、削減 AWS されます。
エンドポイント保護とウイルス対策保護	高	エンドポイント保護とウイルス対策サービスのアプリケーションとメンテナンスは、通常、移行設計の一環として広範囲に自動化されています。
脅威、脆弱性、リスク評価	高	AWS は、コアプラットフォームに重点を置いたこの要素のサポートを提供し、 AWS が提供するメカニズムにより、安全なアーキテクチャでの評価を簡素化します。
データセンターインフラストラクチャプロジェクト管理	高	インフラストラクチャサービスの拡大、更新、廃止のためのインストール作業のためのプロジェクト管理。インフラストラクチャソフトウェアとサービスの一部の管理は残りますが、これはオンプレミスインフラストラクチャよりもはるかにシンプルで、ハードウェアアクティビティは排除されます。
データセンター施設の管理	中～非常に高い	すべてのサーバー、ストレージデバイス、セキュリティアプライアンス、および関連するラックに起因する施設管理作業は、移行されるすべてのものに対して削除されます。ただし、通常、WAN リンクネットワークデバイスやハイブリッドアーキテクチャでオンプレミスに保持されているインフラストラクチャ用の施設を提供する作業もあります。
アプリケーションアーキテクチャ、開発、管理、テスト	低	アジャイル開発ツールチェーンと、必要に応じてテスト環境を構築するためのアプリケーションスタックのインスタンス化と破壊の自動化を組み合わせることで、アプリケーション開発のリードタイムを短縮し、多くの手動テストステップを排除します。
アプリケーションソフトウェアのインストールと設定	Medium	アプリケーションスタックの完全なインストールと設定は、 などのサービスを使用して簡単に自動化 AWS CloudFormation され、 を使用して簡単に設定できるランディングゾーンを使用して簡素化されます AWS Control Tower。
IT サポート	Medium	L1 および L2 サポートの削減は、セルフサービスのプロビジョニングに Service Catalog 機能を使用することで容量とパフォーマンスの問題を削減し、低コストの高可用性アーキテクチャの使用を増やす (停止の削減と自動スケーリングとエッジコンピューティングの設定) ことで実現されます。
データベース管理	最小低	これらのアクティビティはほとんど変更されません。これらは通常、オンプレミスインフラストラクチャと同じレベルで AWS にリソースが供給されます。
インフラストラクチャとセキュリティの要件のキャプチャ、分析、設計	最小限
ドキュメント	最小限
アプリケーションとパフォーマンスのモニタリング	最小限
L3 テクニカルサポート、クエリへの回答、トラブルシューティングと問題解決	最小限
アプリケーションソフトウェアのインストールと設定	最小限
アプリケーション L3 のサポート (予算編成と長期キャパシティプランニングを除く）	最小限

次の表は、ワークロードの削減レベルごとに予想される削減額を示しています。

[レベル]	想定
非常に高い	85%～100%
高	60%～90%
Medium	30%～70%
低	10%～35%
最小限	0%～10%

これらのメトリクスは、生産性の向上を評価し、詳細なビジネスケースに含めるための出発点となります。実際の生産性の向上は、特定の状況によって異なります。範囲の中点と下端の両方で生産性の節約を計算して、一般的なシナリオと保守的なシナリオを見積もると便利です。

プログラムが進行するにつれて、各アクティビティに費やされた時間の実際のデータをロールごとにキャプチャすることが重要です。このデータは、運用を見積もるための改善されたベースを構築し、新しいプロジェクトやサービスの拡張のコストをサポートします。

外部委託された IT 運用とサポートのコスト削減

IT 運用とサポートが主に請負業者に委託または管理されている場合、パートナー AWS 主導 (AMS) を含むマネージドサービスソリューションを提供する AWS パートナーに見積りをリクエストすることで、将来の運用モデル (FOM) のコスト配分を準備することができます。 AWS Managed Servicesまた、「方向性のあるビジネスケースの作成」セクションの「運用コストの最適化の構築」のサブセクションで説明されているように、 AWS アカウントマネージャーに連絡して AMS の料金をリクエストすることもできます。

詳細なビジネスケースでは、ベンチマークの数値を、改訂された AWS サービス部品表と予想されるサービス消費量、AMS パッケージと必要なオプション、および必要なサービスレベルに基づく引用に置き換えます。コストには、1 回限りの実装コンポーネントと消費ベースの実行レートがあります。

残りの IT オペレーション、移行されないサービスで保持する必要があるサポート AWS、契約上のペナルティ (早期終了など) がある場合は 1 回限りのコストを含めます。

レジリエンスバリューモデルを開発する

では AWS、高可用性、ディザスタリカバリ、耐障害性に優れた幅広いアーキテクチャを構築できます。従量制料金とは、使用時にのみ のサービスが課金されることを意味します。これら 2 つの要素を組み合わせることで、耐障害性に優れたコストパフォーマンスが得られます。

さらに、 AWS ccustomers はこれを使用してワークロードの耐障害性を向上させています。IDC 2018 調査では、参加しているお客様が年間停止回数を 73% 削減し、平均復旧時間 (MTTR) を 58% 削減し、生産性の低下を 94% 削減した例を示しています。同じ調査では、耐障害性の向上によって得られる財務上のメリットは、IT インフラストラクチャのコスト削減のメリットよりも 50% 大きいことがわかりました。

さらに、アプリケーションのソフトウェア開発ライフサイクルをモダナイズすることで、さらなる回復力を実現します。ビジネスの俊敏性を高めるためにテスト自動化を備えた CI/CD パイプラインが導入された場合、ソフトウェア欠陥は開発サイクルの早い段階で発見され、ソフトウェアメンテナンスコストが大幅に削減されます。

ビジネスケースでこの価値を評価して含めるには、まずアプリケーションのビジネスオーナーと協力して、移行する各ワークロードの全体的な利益機会の全体像を把握します。 これには、次の項目が含まれます。

• サービスの中断の数、平均期間、性質：

  • サービスの中断の例としては、停止、パフォーマンスの減速、計画的なバッチおよびメンテナンスウィンドウのオーバーラン、主要な関数のバグ、ピーク時のアクセススロットリングなどがあります。

• e コマースシステムなどの収益を生み出すサービスの中断による収益への影響：

  • 中断時間とトランザクションレートに基づいて、サービスの中断によって完了できないトランザクションの見込み数

  • 影響を受ける各トランザクションの平均値

• サポートエンジニアが本番稼働システムの欠陥を解決する時間の追加コストと、開発プロセスの早い段階で発見するコストの比較

• 内部ユーザーの生産性への影響と時間の損失コスト

次に、予想される と、サービス中断による損失時間のより控えめな削減を評価し 、耐障害性を高める必要があります。たとえば、次の項目を含めることを検討してください。

• 高可用性アーキテクチャを使用した停止回数と MTTR の削減、目標復旧時間 (RTO) と目標復旧時点 (RPO) の改善

• 自動スケーリングなどの機能を使用して、速度低下の削減、バッチ処理のオーバーランでの容量スロットリングと回避を排除

• CI/CD パイプラインの実装とインフラストラクチャのスピンアップとスピンダウンの自動回帰テストにより、本番環境でのみ検出されるアプリケーションのバグの数を削減し、コストを最小限に抑えました。

移行およびモダナイズされるアプリケーションのポートフォリオにこれらをまとめ、ケースの年ごとに予想され、より保守的なビジネス価値の数値を計算します。メリットは移行スケジュールに沿って拡大し、貢献するアプリケーションの使用量の増加の期待に沿ってボリュームをスケールインする必要があります。

ビジネスの俊敏性バリューモデルを開発する

ビジネスの俊敏性は、 AWS 顧客が移行する主な理由です AWS。IDC 2018 の顧客調査では、ビジネス俊敏性のメリットは、測定された総メリットの 47% を占め、インフラストラクチャのコスト削減によるメリットの 5 倍以上を占めていると示しました。 AWS

あらゆる変革から生じるビジネス俊敏性のメリットを正確に予測することは困難です。ただし、多数のユーザーをサポートするアプリケーションやビジネス上の差別化の源となるアプリケーションに焦点を当てることで、この利点の重要な部分をモデル化し、ベースラインの詳細なビジネスケースに含めることができます。

移行が進むにつれて、より多くのメリットが定量化可能になるにつれて、ビジネスの俊敏性バリューモデルを段階的に改善し、拡張します。これにより、ビジネスケースが関連付けられるため、プログラムを運営する主要な意思決定サポートツールとして使用できます。

ビジネスの俊敏性バリューモデルを構築するには、次のガイダンスを使用します。

• 次のような、ビジネスパフォーマンスの最大限の改善を推進する機会があるワークロードを選択します。

  • 収益を生み出すワークロード

  • 効率の向上とビジネスからのコストの排除につながるビジネス運用ワークロード

  • 大規模なユーザーベースをサポートするビジネス生産性ツール

• 収益と効率を生成するワークロードについては、以下を実行します。

  • アプリケーションのメジャーアップグレードとマイナーアップグレードが推進されると予想される収益増加または運用効率を現実的かつ保守的に評価します。

  • アプリケーション開発速度の向上とインフラストラクチャのデプロイ時間の短縮により可能になる、1 年あたりのメジャーリリースとマイナーリリースの数 AWS の増加を推定します。このベースラインメトリクスの一部は、IDC レポートに記載されています。

  • 現実的でより保守的なメリットの期待を計算します。ビジネスケースの期間中にマッピングし、それぞれのワークロードが移行されてからしばらくして、効率を最大に引き上げる余裕を持たせます。

• ビジネス生産性向上ツールの場合は、以下を実行します。

  • メジャーアプリケーションとマイナーアプリケーションのアップグレードが推進することが予想される時間の節約について、現実的で保守的な評価を行います。

  • 影響を受けるユーザーベース全体で、人の時間と労力の平均コストを見積もります。

  • 数値を使用してメジャーリリース頻度とマイナーリリース頻度を増やし、ビジネスケースの期間中のメリットを計算します。

デベロッパーの生産性の向上と起動までの時間の短縮により、追加のリソースが不要になるため、各ワークロードの純利益ラインをビジネスケースのキャッシュフローモデルに追加して、割引されたキャッシュフロー、NPV、ROI、MIRR、およびペイバック計算に含めます。