本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 詳細的商業案例
<a name="detailed-business-case"></a>

在此階段中，我們建議驗證和擴展業務案例的範圍，以提供更詳細的支援轉型計畫。快速組合的初始方向性商業案例旨在提供足夠的可信度，以投資基礎步驟和更進一步的詳細規劃。 

開發詳細的商業案例以下列方式支援此規劃程序：
+ 提供財務分析，以告知應遷移和現代化哪些項目、要選取哪些選項，以及如何分階段和排定工作的優先順序
+ 透過重新詳細檢查來驗證、精簡和開發原始方向性財務案例：
  + 基礎設施成本降低潛力
  + 內部 IT 生產力和任何外包操作效率
  + 程式設定、遷移和現代化所需的投資預估值
+ 識別、估計 的規模，並設定程序以追蹤遷移帶來的進一步價值驅動因素

在詳細的商業案例中，您會建立下列項目：
+ 確保授權和投資至少實作遷移第一階段的目標基礎
+ 計劃的基準最低財務績效期望
+ 清楚制定各種遷移設計和優先順序決策的財務基礎，因此當情況和人員在計畫過程中發生變化時，新的領導層可以做出明智的選擇。
+ 深入了解在工作負載遷移和啟動操作時，初始用量資料變為可用後要探索的成本最佳化增量區域
+ 雲端轉型從提高彈性和敏捷性為企業帶來的價值估算 
+ 用於從改善的彈性和敏捷性預估財務回報的相關 KPIs、指標和假設，然後形成推動計畫實現主要利益的基準

## 判斷案例所需的案例
<a name="determine-scenarios-needed"></a>

建置詳細的商業案例時，通常需要開發多個案例，以支援用於商業案例的各種目的。 

**最低變更案例** – 若要評估最低財務績效預期，請準備一個假設最低預期狀態變更的案例。此案例作為最壞情況的後端，在取得對遷移進行投資的命令時提供有用的支援。此案例會針對其他quality-of-service需求，例如可用性和彈性，建立最低預期容量成長程度和最低變更的模型。最低變更會為目前的操作模型建立最低成本和最低資源效率。

**最可能的情況** – 若要通知計劃策略和優先順序決策，請準備反映業務預期會發生的情況。此案例應包括可能的尖峰使用率成長或減少，以及滿足企業對高水準服務品質 （特別是可用性和彈性） 需求的升級成本。

**其他特定案例** – 在仍需要做出可能對業務案例產生重大影響的假設的情況下，開發假設是否成立的案例。不過，我們建議將這些替代案例的數量保持在絕對最小值。全部進度緩慢且變得昂貴、令人困惑且難以維護的 34 個以上案例。盡可能進行實驗，並努力移除更大的假設。

## 驗證和精簡基礎設施和遷移成本模型
<a name="validate-refine-infrastructure-migration-cost-model"></a>

在您完成產品組合分析並準備目標的設計和大小後 AWS 服務，請針對每個案例，精簡 上目前操作模型 (COM) 和未來操作模型 (FOM) AWS 的執行成本估算。通常需要精簡下列項目的預估值：
+ Hypervisor 主機伺服器、裸機伺服器、儲存體、網路裝置、安全設備硬體重新整理、安裝和維護的 **COM 基礎設施成本**。使用案例所需容量的實際定價和折扣等級來計算這些值。
+ **COM 資料中心和共置設施成本**，包括空間、冷卻、電源、機架、不斷電供應 (UPS)、佈線、實體安全系統、調整大小以符合容量，以及案例的高可用性和災難復原 (DR) 層級。
+ **COM 網路服務成本**，包括 WAN 連結、內容交付網路和虛擬私有網路 (VPNs) 的成本，其計算方式是針對案例的連線、頻寬、輸送量和延遲需求使用合約定價。
+ 根據現有合約的 **COM 應用程式和基礎設施軟體成本**，以提供案例的成長或減少用量。
+ **FOM AWS 公用程式成本**，包括視需要的技術支援和受管服務，以精簡的服務架構、執行個體大小、偏好的定價模型、預期用量和用量波動為基礎。
+ **FOM 應用程式授權**是以最終應用程式設計、執行應用程式的基礎設施組態、隨時間的成長，以及授權可轉移性規則為基礎。
+ **FOM 遷移和現代化成本估算**，改進以反映案例的基準遷移波動計劃，並詳細說明為每個工作負載提供成本，尤其是要進行轉換、重新購買或重構的工作負載。 
+ **FOM 解除委任成本**，包括資產註銷和合約提前終止成本的預估、修訂以反映基準遷移波動計畫中的解除委任時間、驗證哪些資產可以重新利用，以及可以切換哪些資產以將註銷降至最低，以及實體資產和媒體的處置成本。 
+ **改善遷移平行執行成本**，以反映每個遷移切換和每個現有服務停用的時間。

## 改善 IT 生產力和 IT 操作，並支援效率值模型
<a name="refine-it-productivity-it-operations-support-efficiency-value-model"></a>

與定向商業案例一樣，有兩種主要方法可以精簡和開發有關 IT 操作和支援的價值模型。您選擇的方法取決於 COM 是內部管理，還是與承包商或外包服務一起管理：

### 改善內部團隊生產力
<a name="internal-team-productivity-improvement.53441e7b-2d1e-5e42-81f0-ed1ddac9abde"></a>

在內部管理 IT 操作和支援的情況下，商業案例的重點如下：
+ 識別和量化從遷移和範圍中包含的任何操作自動化獲得的生產力
+ 驗證內部團隊釋放的時間可以輕鬆且有生產力地套用到其他通常價值更高的活動，為團隊提供進展和更大回報的機會，並為組織提供更多價值

評估效益需要分析團隊中每個角色中每個成員在各種一般活動上花費的時間，以及不同活動預期工作負載減少的指引。 

下表針對耗用大量 IT 操作並支援團隊中不同角色工作的任務，提供依活動區分的工作負載減少典型層級的初始指引。資料表包含如何實現生產力的描述。 

**注意**  
** **列出的活動通常由多個不同角色的團隊成員執行，因此應在整個團隊中的角色集中評估每個任務的生產力節省。例如，在基礎設施塔組織 （例如運算、儲存和聯網） 的 IT 營運團隊中，每個塔的塔線可能很常見資本支出規劃和預算。 


| 
| 
| 操作和支援活動 | 節省程度 | 生產力驅動因素 | 
| --- |--- |--- |
| 基礎設施設計 | 中 | 設計經過簡化，需要考慮的參數較少。 | 
| 資本支出規劃和預算 | 高 | 以 OPEX 為中心的彈性服務可移除幾乎所有預算和規劃問題。 | 
| 購買 | 高 |  AWS 帳戶 建立 後，採購會大幅簡化。 | 
| 容量規劃 | 中等到非常高 | 網路和運算容量管理工作負載通常都已完全消除，而對於儲存體而言，它已大幅簡化 | 
| 調校 | 非常高 | 受管服務不需要調校，其他 服務則幾乎不需要調校，因為執行個體可以隨時變更大小。 | 
| 管理硬體故障 | 非常高 | 處理雲端硬體的所有層面都由 透明處理 AWS。 | 
| 監控伺服器可用性和通訊 | 高 | 透過 AWS 工具支援和自動化，可廣泛簡化監控和通訊。 | 
| 安全管理 | 中 | 工作負載會隨著 AWS 安全功能以及 AWS 擁有 AWS 雲端 硬體、軟體、聯網和設施[的安全責任](https://aws.amazon.com/compliance/shared-responsibility-model/)而大幅減少。 | 
| 網路和儲存升級、維護和修補程式。 | 非常高 | 雲端中網路和儲存維護的所有層面都由 透明處理 AWS。 | 
| 機架和堆疊 – 硬體物流 | 非常高 | 管理雲端硬體的所有層面都由 透明處理 AWS。 | 
| 備份 | 中 | 透過 AWS 工具、彈性儲存系統和自動化，可廣泛簡化備份。 | 
| 受管服務 （例如 Amazon S3 AWS Lambda、Amazon RDS 和 AWS Fargate) | 非常高 | 受管服務會在由 完全管理的環境中執行 AWS，因此不需要維護、修補、監控或佈建管理活動。 | 
| 裝置和服務設定和試運轉 | 非常高 | 遷移至 AWS 之資產的硬體設定活動通常會減少，但用於建立 VPNs WAN 連線裝置除外。 AWS Direct Connect AWS  | 
| 端點保護和防毒保護 | 高 | 端點保護和防毒服務的應用程式和維護通常在遷移設計中廣泛自動化。 | 
| 威脅、漏洞和風險評估 | 高 | AWS 提供對此元素的支援，專注於核心平台，以及 AWS 提供安全架構的機制可簡化評估。 | 
| 資料中心基礎設施專案管理 | 高 | 安裝工作的專案管理，用於擴展、重新整理或停用基礎設施服務。雖然基礎設施軟體和服務的某些管理仍然存在，但比現場部署基礎設施更簡單，且硬體活動已消除。 | 
| 資料中心設施管理 | 中等到非常高 | 可歸因於所有伺服器、儲存裝置、安全設備和相關聯機架的設施管理工作，會針對所有遷移的項目移除。不過，對於為 WAN 連結網路裝置和混合架構中保留在內部部署的任何基礎設施，某些工作通常仍然有效。 | 
| 應用程式架構、開發、管理和測試 | 低 | 使用敏捷的開發工具鏈，結合應用程式堆疊執行個體化和銷毀的自動化，以視需要建置測試環境，減少應用程式開發的前置時間，並消除許多手動測試步驟。 | 
| 安裝和設定應用程式軟體 | 中 | 完整的應用程式堆疊安裝和組態可使用 等服務輕鬆自動化，並透過使用 輕鬆設定的登陸區域進行 AWS CloudFormation 簡化 AWS Control Tower。 | 
| IT 支援 | 中 | 透過使用 Service Catalog 功能進行自助式佈建、增加低成本高可用性架構的使用 （減少中斷並設定自動擴展和邊緣運算），來減少 L1 和 L2 支援。 | 
| 資料庫管理 | 最低-低 | 這些活動大部分保持不變。它們通常在 AWS 與內部部署基礎設施相同的層級上獲得資源。 | 
| 基礎設施和安全性需求擷取、分析和設計 | 極小 | 
| 文件 | 極小 | 
| 應用程式和效能監控 | 極小 | 
| L3 技術支援、回應查詢，以及疑難排解和問題解決 | 極小 | 
| 安裝和設定應用程式軟體 | 極小 | 
| 應用程式 L3 支援 （預算和長期容量規劃除外） | 極小 | 

下表顯示每個工作負載減少層級的預期節省成本。


| 
| 
| Level | 預期 | 
| --- |--- |
| 非常高 | 85% - 100% | 
| 高 | 60% - 90% | 
| 中 | 30% - 70% | 
| 低 | 10% - 35% | 
| 極小 | 0% - 10% | 

這些指標提供評估生產力收益的起點，並將它們包含在詳細的商業案例中。實際的生產力增加取決於特定情況。計算範圍中點和下端的生產力節省，以估計典型和保守的案例會很有用。

隨著計畫進行，按角色擷取每個活動所花費時間的實際資料非常寶貴。該資料為預估操作建置了改善的基礎，並支援新專案和擴展服務的成本。

### 委外 IT 操作並支援降低成本
<a name="outsourced-it-operations-and-support-cost-reduction.70fe627e-2de5-52d3-88db-07b52dd802eb"></a>

當 IT 操作和支援主要與承包商進行外包或管理時，未來操作模型 (FOM) 的成本分配可以透過向提供受管服務解決方案的 AWS 合作夥伴請求引號來準備，包括 AWS 合作夥伴主導的 [AWS Managed Services](https://aws.amazon.com/managed-services/partners/)。您也可以聯絡您的 AWS 客戶經理並直接請求 AMS 的價格，如 [建立定向商業案例](directional-business-case.md)區段中的 [在營運成本最佳化中建置](directional-business-case.md#building-operational-cost-optimization)子節中所述。

對於詳細的商業案例，根據修訂後的物料 AWS 服務 清單和預期的服務使用量、AMS 套件和所需的任何選項，以及所需的服務層級，以引號取代任何基準數字。成本會有一次性實作元件和以耗用量為基礎的執行速率。 

包含任何剩餘的 IT 操作、必須為不會遷移到的任何服務保留的支援 AWS，以及任何合約處罰時的一次性成本 （例如，提早終止）。

## 開發彈性值模型
<a name="develop-resilience-value-model"></a>

在 上 AWS，您可以建構各種高可用性、災難復原和容錯架構。以使用量為基礎的定價表示服務僅在使用時才會收費。這兩個因素共同提供卓越的彈性成本效能。 

此外， AWS 客戶已使用此功能來改善工作負載的彈性。[IDC 2018 年調查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)提供參與客戶每年達到 73% 減少中斷、平均復原時間 (MTTR) 減少 58%，以及生產力降低 94% 的範例。相同的調查顯示，提高彈性所產生的財務效益比 IT 基礎設施成本降低效益高出 50%。 

此外，透過現代化應用程式的軟體開發生命週期來實現進一步的彈性。引進具有測試自動化的 CI/CD 管道以支援更高的業務敏捷性時，軟體瑕疵會在開發週期的早期發現，大幅降低軟體維護成本。

若要在商業案例中評估並包含此值，請先與應用程式企業擁有者合作，為要遷移的每個工作負載建立*整體利益機會*的影像**。 **這可能包含下列項目：
+ 服務中斷的數量、平均持續時間和性質
  + 服務中斷的範例包括中斷、效能降低、規劃的批次和維護時段過度執行、關鍵函數中的錯誤，以及在尖峰期間存取限流。 
+ 電子商務系統等產生營收的服務中斷對營收的影響
  + 根據中斷時間和交易費率，可能無法透過服務中斷完成的交易數量
  + 每個受影響交易的平均值
+ 相較於在開發程序中稍早發現瑕疵的成本，支援工程師解決生產系統中瑕疵所需的額外成本
+ 影響內部使用者的生產力和損失時間的成本

然後評估預期和更保守地減少因服務中斷而損失的時間** **，而增加的恢復能力應該產生。例如，請考慮包含下列項目：
+ 使用高可用性架構減少中斷和 MTTR 的數量，並改善復原時間目標 (RTO) 和復原點目標 (RPO)
+ 使用自動擴展等功能，減少減慢速度、消除容量調節和避免批次處理溢位
+ 透過實作 CI/CD 管道，以及在基礎設施上進行自動化迴歸測試，減少僅在生產環境中發現的應用程式錯誤數量，以將成本降至最低

將這些項目放在待遷移和現代化之應用程式的產品組合中，並計算每個案例每年的預期和更保守的商業價值數字。優點應與遷移排程保持一致，然後根據貢獻應用程式的用量成長預期來擴展磁碟區。 

## 開發業務敏捷性價值模型
<a name="develop-business-agility-value-model"></a>

業務敏捷性是 AWS 客戶遷移至 的主要原因 AWS。 [IDC 2018 年客戶調查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)指出，對於他們而言，業務敏捷性利益佔衡量的總利益的 47%，以及基礎設施成本降低所產生的利益的五倍以上。 AWS 

準確預測任何轉型將產生的所有業務敏捷性優勢都具有挑戰性。不過，透過專注於支援大量使用者或是業務差異來源的應用程式，您可以將此優勢的重要部分建模並納入基準詳細業務案例。

隨著遷移的進行，隨著更多的效益變得可量化，逐步精簡和擴展業務敏捷性價值模型。這可讓業務案例保持相關性，以便它可以用作引導程式的主要決策支援工具。

若要建置業務敏捷性價值模型，請使用下列指引：
+ 選取有機會推動最大業務效能改善的工作負載，例如：
  + 產生營收的工作負載 
  + 具有範圍的業務營運工作負載，可提高效率並從業務中移除成本
  + 支援大型使用者群的業務生產力工具
+ 對於營收和效率產生工作負載，請執行下列動作：
  + 對預期主要和次要應用程式升級可推動的營收成長或營運效率進行實際且更保守的評估。
  + 估計每年增加的主要和次要版本數量， AWS 以提高應用程式開發速度並縮短基礎設施部署時間。IDC 報告中提供了此項目的一些基準指標。
  + 計算實際且更保守的利益期望。在商業案例期間映射它們，在遷移個別工作負載之後，提供提升至完全效率的額度。
+ 對於業務生產力工具，請執行下列動作：
  + 對預期主要和次要應用程式升級可推動的時間節省進行實際且更保守的評估。
  + 估計受影響使用者群中人員時間和精力的平均成本。
  + 使用數字來提高主要和次要發行頻率，並計算業務案例期間的效益。

由於提高開發人員生產力並縮短啟動時間不需要額外的資源，請將每個工作負載的淨收益行新增至商業案例現金流模型，以包含在折扣的現金流、NPV、ROI、MIRR 和回報計算中。