建立有方向性的商業案例

來自整個企業的利益相關者應了解和接受商業案例，以便在整個過程中進行每個步驟的轉型。

在早期階段，快速從遷移計畫顯示足夠的潛在價值非常重要，這樣您就可以保護規劃和建立計畫所需的資源。具方向性的商業案例旨在透過可及早收集的有限資料，提供合理信心來實現令人信服的商業價值。

建立計畫後，會進一步開發商業案例。詳細案例提供更高的準確性、更完整的程式值，以及規劃優先順序的深入解析。它定義和量化組織購買的目標計劃業務成果，並設定了您的計畫控管辦公室可以引導計畫並衡量其成就的基準。

修正定向商業案例的範圍

方向性商業案例通常會在 2-4 週內快速組合。它需要產生足夠的可信度，以便您可以保護資源以建立核心團隊、在需要時與 AWS 合作夥伴互動，並且至少完成優先應用程式評估和產品組合分析以及遷移規劃階段。

一般而言，支援產品組合遷移的方向性商業案例會建立為下列其中一項：

• 隨需基礎設施環境與遷移後 AWS 服務 架構之間的簡單總擁有成本 (TCO) 比較。此比較顯示指定工作負載磁碟區預期執行率的差異。

• 商業案例 ，顯示遷移至 AWS 包含遷移成本與保持原狀的淨現值 (NPV)、投資報酬率 (ROI)、償還期、修改後內部報酬率 (MIRR) 和 3–5 年現金流分析。

方向性商業案例範圍通常僅限於下列其中一項：

• 基礎設施技術成本的比較

• 基礎設施技術和操作成本的比較

一般而言，產品組合越大，案例的開發程度就越少。這是因為可以做出更廣泛的假設，而不會顯著影響結果。對於較小的產品組合，任何變更都會產生更大的影響，因此需要更多詳細資訊。

首先，建立基礎基礎設施成本比較。然後決定比較是否足夠吸引人，再繼續。通常，超過 400 部伺服器的產品組合在 3 年操作內 AWS，或 5 年內 250 部伺服器，就單獨降低基礎設施成本上會顯示正面的商業案例，但這可能會有所不同。對於較小的產品組合，可能需要更多詳細資訊。

相反地，在此階段檢查其他商業價值元件很少有用，例如衍生自改善彈性或業務敏捷性的值，除非遷移範圍總計少於約 5 個工作負載或 50 個伺服器。

焦點值驅動因素

基礎設施技術 TCO 比較比較基礎設施成本的模型與執行工作負載所需的基本物料 AWS 服務 清單模型，具有同等的效能和可用性。許多最佳化都可以完成。不過，在此階段，重點在於下列清單，因為它們更容易評估，而且通常會節省約 30% 的 TCO，這足以繼續：

• 運算彈性 – 將用量不是 100% 的伺服器，例如執行 8x5 (24% 用量）、10x5 (30%) 或 10x6 (36%) 的開發或 UAT 伺服器，以及執行 2% 的災難復原 (DR) 伺服器，映射到僅在使用時才計費的隨需服務。

• 使用節省計劃採購 – 計劃使用適當的節省計劃採購生產伺服器和其他高用量 （大於 36%) 的伺服器，將成本降低高達 75%。選項包括 1 年期和 3 年期的承諾，具有不同級別的預付付款，以確保更高的折扣。

• 移除殭屍 – 識別 CPU 使用率低於 2% 的伺服器，您可以確認不再需要這些伺服器，並從成本分析中移除它們。

• 運算適當大小 – 使用 CPU 和記憶體使用率時間序列資料，評估每個伺服器所需的運算能力和記憶體。然後選取要配合的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。

• 關聯式資料庫管理系統 (RDBMS) 授權大小調整 – 在資料庫伺服器上運算大小調整後重新評估 RDBMS 授權需求、比較自帶授權 (BYOL) 和從中取得授權 AWS，並探索 Amazon Relational Database Service (Amazon RDS) 的潛力以節省成本。

• 儲存 – 適當調整所需的總儲存磁碟區大小，並識別產品組合中每秒的輸入/輸出操作 (IOPS) 需求。決定可以移至具有不同 SLAs 和成本的物件儲存體的程度。

資料需求

了解初始評估資料要求中的表格會顯示建置方向性商業案例的每個部分所需的資料，以及它是強制性還是選擇性的。

若要建置案例，您需要初始規劃資料的基礎設施子集加上成本資料。決定如何識別要包含的基礎設施取決於您的業務目標：

• 如果程式的目標是遷移和現代化特定應用程式，請考量共用的基礎設施，根據應用程式需求建置基礎設施產品組合。

• 如果程式的目標是以基礎設施為中心，例如從租用即將到期的資料中心遷移，則基礎設施 TCO 比較不需要應用程式映射。

標示為選用的資料 （例如伺服器的 CPU 和記憶體尖峰使用率） 通常可以用標準基準值取代。您可以與 AWS 合作夥伴或 AWS 專業服務討論此問題。或者，您可以從產品組合的一部分中可用的資料點推斷值 （例如 Hypervisor 收集的資料）。產品組合越大，其準確性就越高。

建置基礎設施 TCO 比較

工具對於建構基礎設施 TCO 比較至關重要。AWS Professional Services 或 AWS 合作夥伴可以提供所有類型定向案例的協助，特別是如果您計劃讓他們參與以協助更廣泛的遷移程序時。

有工具可以執行下列動作：

• 收集庫存資料。

• 收集使用率資料。

• 提供準確的現狀基礎設施成本基準資料。

• 識別和移除殭屍。

• 進行適當大小的評估。

• 建議購買選項。

• 比較軟體授權選項。

• 產生簡單的圖形現金流分析。

從 遷移評估器 AWS 是一個選項。它提供所有這些功能作為免費受管服務。您可以透過 AWS 帳戶管理員或遷移能力合作夥伴，或在線上提交請求，來請求 AWS 遷移評估器。Migration Evaluator 專門設計為單點解決方案，可快速產生基礎設施技術 TCO 比較。

主要優點：

• 免費

• 無代理程式探索或庫存資料的手動組態，其中以工具為基礎的探索受到限制

• 協助部署、組態、資料收集和建置基本案例或定向商業案例的專用支援

• SaaS 操作的便利性，但 可以完全在客戶網路中執行資料收集，以支援在載入分析引擎之前清除

• Microsoft 授權大小調整的強大支援

• 完整的資料匯出功能

金鑰限制：

• 僅評估 x86 架構伺服器 (Windows 和 Linux)

• 設定或校正基準即用成本資料的有限選項

• 不支援建模操作成本最佳化

• 不支援遷移成本建模

• 沒有直接支援建置 TCO 比較以外的商業案例

如果您決定使用商業探索工具進行產品組合探索和分析功能，例如應用程式堆疊和相互依存性探索，它通常也會提供基礎設施 TCO 比較。如需使用工具進行產品組合探索和評估的指引，請參閱評估探索工具的需求。若要檢閱和比較市場領先工具的主要功能，請參閱探索、規劃和建議遷移工具。

在營運成本最佳化中建置

IT 操作生產力改善通常是遷移的重要價值貢獻者。根據 International Data Corporation (IDC) 白皮書培養商業和組織轉型以透過 Amazon Web Services 產生商業價值，平均而言，遷移至 後 AWS，IT 營運人員的生產力會透過遷移增加 62%。不過，調整大小和在方向性案例中包含這些優點有兩個挑戰。

首先，評估全方位的生產力收益需要廣泛的資料收集，並且更適合詳細的商業案例。此挑戰可以透過專注於幾個元素來解決，這些元素使用簡單的基準資料更容易評估和調整大小，但仍顯示顯著優勢。

其次，將生產力作為降低成本的來源，可能會在關鍵客戶利益相關者和計劃成員之間產生關注和負面。請務必清楚了解將如何實現利益，以及這對受影響人員的意義。釐清這只會增強團隊的角色，可以避免這些問題：

• 遷移計畫包含開發內部營運人員並將其移入新角色的軌道，例如加入 DevSecOps 團隊建置基礎設施做為程式碼自動化，以及測試自動化，以推動團隊成長。

• 透過調整和調整操作外包合約的大小，即可實現優勢，以便內部員工可以提高他們對更高價值活動的關注

根據您想要考慮的操作轉換來建構此商業案例元素的方法：

• 如果您有現有的內部營運團隊，請提升團隊成員的技能，並顯示預期的生產力改善。

• 或者，從您目前的操作解決方案遷移到 AWS Managed Services (AMS) 或從 AWS 合作夥伴遷移到替代的受管服務產品。

針對第一次轉換，若要取得案例可包含的改善生產力的保守財務預估，我們建議下列事項：

1. 特別專注於伺服器管理操作生產力。它往往是操作工作的重要比例，可以更輕鬆地評估，並且稍後更容易驗證。

2. 根據每個全職同等 (FTE) 員工可以管理的伺服器數量基準，計算所需的人員配置。在內部部署中，該數量約為 150 個伺服器。在 上 AWS，大約有 400 個伺服器。

3. 將這些指標套用到內部部署伺服器的數量，與 EC2 執行個體的數量相比。

4. 將節省的時間與整個營運團隊的混合成本費率相乘。

然後，您可以透過驗證結果不超過下表中的角色獲得的平均生產力 （資料來源為 IDC 白皮書培養商業和組織轉型，以透過 Amazon Web Services 產生商業價值。

Role	效率增益
IT 基礎設施管理	62%
IT 支援	59%
應用程式管理	43%
資料庫管理	19%
應用程式開發	25%

對於第二個轉換，您可以直接比較範圍內產品組合的目前總操作和支援成本，以及考慮的受管服務成本，以增加營運成本節省。

若要取得受管服務的成本，請將您提議的物料 AWS 清單、服務層級選擇 (Plus 或 Premium) 和 AMS 套件 (AMS Accelerate 或 AMS Advanced) 提供給 AWS 您的帳戶管理員或任何AWS Managed Services 合作夥伴。這將為您提供 受管服務的總成本：AWS 服務 轉換解決方案的元件。同樣地，您可以從根據自己的參數提供自己的受管服務套件的 AWS 合作夥伴取得定價。

擴展到全方位商業案例

一般而言，若要組合全方位的商業案例，請建立 TCO 比較，無論是否具有 IT 生產力元素，並預估所有遷移和現代化成本。然後建立現金流程，涵蓋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 類型中所討論，請考慮在遷移和現代化的第一階段使用重新託管、重新放置或轉換策略。這些 R 策略可能會加速初始回報、降低實作風險，以及短期內改善商業案例。讓您的應用程式團隊大幅簡化在 AWS 環境中執行的應用程式。準備詳細的商業案例時，最好新增重構 （重新建構） 特定應用程式的預估值。

依策略估算遷移的工作量

每次遷移都不同。在遞交任何預算或計劃之前，種子工作負載預估將由負責專案的團隊進行的遷移活動，無論是您的內部應用程式團隊、 AWS 專業人員服務或 AWS 合作夥伴組織。

為了協助建置方向性案例，下表提供不同處理方式的指示性工作範圍。這些範圍假設medium-to-large產品組合正在遷移，且遷移團隊經過訓練且經驗豐富。對於小型產品組合，最好讓負責遷移的團隊為定向案例準備預估值。

遷移策略	估算程序	元素	人員時數	人員時數
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 公用程式成本的增加

• 不再執行遷移工作負載之現有基礎設施的停用成本

對於資料交換，請檢查您的總資料磁碟區，並評估使用聯網的可行性。如果您已在遷移後提前在 WAN 上佈建AWS Direct Connect連結AWS VPN或從 佈建 AWS 至某個點以供操作使用，則您可以使用該資源，直到其服務配額為止。

如果您的網路容量不足，使用虛擬私有網路 (VPN) 短期增加網際網路頻寬通常是具成本效益的解決方案。如果沒有，例如 AWS Snowball Edge和 等 AWS 媒體交換裝置在大多數情況下AWS Snowball Edge都會提供解決方案 AWS 區域。此外，對於非常大量的資料遷移，請考慮包含 的預算AWS DataSync，這可提高可靠性並加速傳輸，無論使用的媒體為何。

對於商業案例的現金流程分析元素而言，建立 AWS 服務漸進和現有基礎設施漸進漸進的模型非常重要。在這個階段，您不太可能有波動計畫來確定何時產生成本。我們建議下列作法：

• 以與遷移相比 AWS 的固定速率提高 的成本。

• 縮減您計劃在相同持續時間內以固定速率停用的現有基礎設施的成本。

在現有基礎設施下降前 1-2 個月開始 AWS 成本上升。這提供 1 個月的 AWS 公用程式用量，以針對每個波次執行遷移。其中包括測試時間，以及完成停止取代基礎設施產生成本所需的除役工作所需的額外時間。

預估除役成本

停用無法重新部署的設備，並以合法且對環境友善的方式處置，可能會產生一些小額成本。不過，對於有方向性的商業案例，通常唯一的可能重大總和是沖銷所取代資產任何剩餘帳面價值的成本。

對於有方向性的商業案例，我們建議您執行下列動作：

• 檢閱您的資產清單。

• 識別要停用的那些。

• 若要減少沖銷，請檢查切換裝置的機會，以便清單中較新的裝置可用來取代較舊且已完全棄用的資產。

• 評估屆時將停用的資產的未來帳面價值。

• 將此納入為停用的遷移成本。

組合和調整全方向商業案例

在您為每組案例準備完整的一組成本之後，請建構每個案例的折扣現金流量陳述式，並繪製它們的圖形。我們建議您在硬體重新整理週期的同一期間建置有方向性的商業案例。伺服器、儲存和網路裝置通常需要 5 年的時間。當您使用與硬體重新整理週期相同的期間時，每個案例的現狀成本中只會包含一次重新整理的成本。

然後計算取得核准以進入計劃下一個階段所需的關鍵財務指標。我們通常包含下列項目：

• 用來衡量評估成本降低和生產力提高的絕對值的淨現值 (NPV)

• 以月為單位的傳回期間，以驗證傳回是否足夠快速

• 最終執行速率比較，以驗證程序是否在期間內消耗足夠的成本

• 投資報酬率 (ROI) 和修改後投資報酬率 (MIRR)，以評估相較於組織可能優先考慮的其他資本需求，計畫相對財務績效

使用案例的第一個反覆運算來判斷預期的財務效能是否意味著應進行精簡，如下列範例所示：

• 如果傳回太慢，請考慮加速和降低遷移成本的選項，如下所示：

  • 使用 AWS 合作夥伴或 AWS 專業服務來擴展可用資源，並以更基本的模式進一步平行化遷移工作負載。

  • 對於在 VMware 中執行的工作負載，請至少在初始階段比較重新放置策略與重新託管或轉換策略。使用重新定位策略可以降低遷移成本並提高遷移速度。

  • 在技術上可行的情況下，將需要更複雜轉換或重構 （重新架構） 策略的工作負載推送到初始業務案例範圍以外的未來階段。

• 如果 ROI 和 MIRR 太低，請考慮下列事項：

  • 您考慮的案例是否過於保守？ 您是否有反映最可能容量增長和彈性需求的案例？ 您是否有比較成本的案例，包括目標內服務品質的提高？

  • 您能否縮小應用程式產品組合的範圍，以專注於將產生更強大傳回的工作負載，例如目前使用率較低或災難復原 (DR) 需求昂貴的工作負載？

  • 可以縮小應用程式產品組合的範圍，以最初排除在商業上達成較少的特定工作負載嗎？ 例如，您可以延遲第三方軟體授權因在公有雲端基礎設施中部署的不同條款而變得更昂貴的工作負載嗎？

• 如果最終執行速率比較不符合預期目標，請探索以下內容：

  • 首先，確認其他指標符合預期。有方向性的商業案例主要是顯示有足夠的財務機會來證明開始下一階段的遷移準備。

  • 識別在遷移初始階段 AWS 後，繼續改善 成本效能的機會清單。

在準備詳細的商業案例時，包括機會清單的評估。此外，在持續維護案例和遷移完成後month-to-month成本最佳化程序中，納入機會評估。