本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
詳細的商業案例
在此階段,我們建議驗證和擴展業務案例的範圍,以提供更詳細的支援轉型計畫。快速組合的初始方向性商業案例旨在提供足夠的信心,以投資於基礎步驟和更進一步的詳細規劃。
開發詳細的商業案例以下列方式支援此規劃程序:
-
提供財務分析,以告知應遷移和現代化的內容、要選取的選項,以及如何逐步設定工作並排定優先順序
-
透過重新詳細檢查來驗證、精簡和開發原始方向性財務案例:
-
基礎設施成本降低潛力
-
內部 IT 生產力和任何外包操作效率
-
程式設定、遷移和現代化所需的投資預估值
-
-
識別、估計 的規模,並設定程序以追蹤遷移帶來的更多價值驅動因素
在詳細的商業案例中,您會建立下列項目:
-
確保至少實作遷移第一階段之授權和投資的目標基礎
-
計劃的基準最低財務績效期望
-
清楚制定各種遷移設計和優先順序決策的財務基礎,因此當情況和人員在計畫過程中發生變化時,新的領導可以做出明智的選擇。
-
在工作負載遷移和啟動操作時,在初始用量資料可用後,探索成本最佳化的增量區域
-
雲端轉型從提高彈性和敏捷性為企業帶來的價值估算
-
用於估計財務回報的相關聯 KPIs、指標和假設,其來自改善的彈性和敏捷性,然後形成了推動計畫實現主要利益的基準
判斷案例所需的案例
建置詳細的商業案例時,通常需要開發多個案例,以支援商業案例使用的各種目的。
最低變更案例 – 若要評估最低財務績效預期,請準備一個假設最低預期狀態變更的案例。此案例最壞的情況是,在取得對遷移進行投資的命令時, 是有用的支援。此案例會針對其他quality-of-service需求,例如可用性和彈性,建立最低預期容量成長程度和最低變更的模型。最小變更會為目前的操作模型建立最低的成本和資源效率低下。
最可能的情況 – 若要通知計劃策略和優先順序決策,請準備反映業務預期會發生的情況。此案例應包括可能的尖峰使用率成長或減少,以及符合企業對高水準服務品質 (特別是可用性和彈性) 需求的升級成本。
其他特定案例 – 在仍需要做出可能對業務案例產生重大影響的假設時,請針對假設保持成立和不成立的案例進行開發。不過,我們建議將這些替代案例的數量保持在絕對最小值。總共建立超過三到四個案例會減慢進度,並變得昂貴、令人困惑且難以維護。盡可能進行實驗,並努力移除更大的假設。
驗證和精簡基礎設施和遷移成本模型
完成產品組合分析並準備目標的設計和大小後 AWS 服務,請針對每個案例,精簡目前操作模型 (COM) 和未來操作模型 (FOM) AWS 的執行成本估算。通常需要精簡下列項目的預估值:
-
Hypervisor 主機伺服器、裸機伺服器、儲存體、網路裝置、安全設備硬體重新整理、安裝和維護的 COM 基礎設施成本。使用案例所需容量的實際定價和折扣等級來計算這些值。
-
COM 資料中心和共置設施成本,包括空間、冷卻、電源、機架、不斷電供應 (UPS)、佈線、實體安全系統、調整大小以符合容量,以及案例的高可用性和災難復原 (DR) 層級。
-
COM 網路服務成本,包括 WAN 連結、內容交付網路和虛擬私有網路 (VPNs) 的成本,這些成本是針對案例的連線、頻寬、輸送量和延遲需求使用合約定價計算。
-
根據現有合約的 COM 應用程式和基礎設施軟體成本,以提供案例的成長或減少用量。
-
FOM AWS 公用程式成本,包括技術支援和視需要的受管服務,根據精細的服務架構、執行個體大小、偏好的定價模型、預期用量和用量波動而定。
-
FOM 應用程式授權是以最終應用程式設計、執行應用程式的基礎設施組態、隨時間的成長,以及授權可轉移性規則為基礎。
-
FOM 遷移和現代化成本估算,經過精簡化以反映案例的基準遷移波動計畫,並詳細說明為每個工作負載提供成本,尤其是要進行重建、重新購買或重構的工作負載。
-
FOM 解除委任成本,包括資產註銷和合約提前終止成本的預估、修訂以反映基準遷移波動計劃的解除委任時間、驗證可重新規劃的資產和可切換的資產,以將註銷降至最低,以及實體資產和媒體的處置成本。
-
改善遷移平行執行成本,以反映每個遷移切換和每個現有服務停用的時間。
改善 IT 生產力和 IT 操作,並支援效率值模型
如同有方向性的商業案例,有兩種主要方法可以精簡和開發有關 IT 操作和支援的價值模型。您選擇的方法取決於 COM 是內部管理,還是與承包商或外包服務一起管理:
內部團隊生產力改善
在內部管理 IT 操作和支援的情況下,商業案例的重點如下:
-
識別和量化遷移和範圍中包含的任何操作自動化的生產力收益
-
驗證內部團隊釋放的時間可以輕鬆且有生產力地套用至其他通常價值較高的活動,為團隊提供進展和更大獎勵的機會,並為組織提供更多價值
評估團隊中每個角色中的每個成員花費在各種一般活動上的時間,以及不同活動工作負載預期減少的指引。
下表針對使用大量 IT 操作並支援團隊中不同角色工作的任務,提供依活動區分的工作負載減少典型層級的初始指引。資料表包含如何實現生產力的描述。
注意
列出的活動通常由具有數個不同角色的團隊成員執行,因此應在整個團隊中的角色集中評估每個任務的生產力節省。例如,在由基礎設施塔 (例如運算、儲存和聯網) 組織的 IT 營運團隊中,每個塔的塔線可能很常見,因此資本支出規劃和預算編列。
操作和支援活動 |
節省程度 |
生產力驅動因素 |
---|---|---|
基礎設施設計 |
中 |
設計已簡化,需要考慮的參數較少。 |
資本支出規劃和預算編列 |
高 |
以 OPEX 為中心的彈性服務可消除幾乎所有預算和規劃問題。 |
購買 |
高 |
建立 後 AWS 帳戶 ,採購會大幅簡化。 |
容量規劃 |
中等至非常高 |
網路和運算容量管理工作負載通常全部消除,而對於儲存體而言,它大幅簡化 |
調校 |
極高 |
受管服務不需要調校,其他 服務則幾乎不需要調校,因為執行個體可以隨時變更大小。 |
管理硬體故障 |
非常高 |
處理雲端硬體的所有層面都由 透明處理 AWS。 |
監控伺服器可用性和通訊 |
高 |
透過工具支援和自動化,可 AWS 廣泛簡化監控和通訊。 |
安全管理 |
中 |
工作負載會因 AWS 安全功能和 AWS 擁有 AWS 雲端 硬體、軟體、聯網和設施的安全責任 |
網路和儲存升級、維護和修補程式。 |
非常高 |
雲端中網路和儲存維護的所有層面都由 透明處理 AWS。 |
機架和堆疊 – 硬體物流 |
非常高 |
管理雲端硬體的所有層面都由 透明處理 AWS。 |
備份 |
中 |
透過 AWS 工具、彈性儲存系統和自動化,可廣泛簡化備份。 |
受管服務 (例如 Amazon S3、Amazon RDS AWS Lambda和 AWS Fargate) |
非常高 |
受管服務會在完全由 管理的環境中執行 AWS,因此不需要維護、修補、監控或佈建管理活動。 |
裝置和服務設定和試運轉 |
極高 |
遷移至 的資產硬體設定活動 AWS 通常會減少,但用於建立 VPNs或 AWS 資料中心 AWS Direct Connect 連線的 WAN 連線裝置除外。 |
端點保護和防毒保護 |
高 |
端點保護和防毒服務的應用和維護通常在遷移設計中廣泛自動化。 |
威脅、漏洞和風險評估 |
高 |
AWS 支援此元素,著重於核心平台,以及 AWS 提供安全架構的機制,可簡化評估。 |
資料中心基礎設施專案管理 |
高 |
安裝工作的專案管理,用於擴展、重新整理或停用基礎設施服務。雖然基礎設施軟體和服務仍有一些管理,但比現場部署基礎設施更簡單,而且硬體活動也已消除。 |
資料中心設施管理 |
中等至非常高 |
可歸因於所有伺服器、儲存裝置、安全設備和相關聯機架的設施管理工作,會針對所有遷移的項目移除。不過,某些工作通常仍然用於為 WAN 連結網路裝置提供設施,以及為混合架構中保留在內部部署的任何基礎設施提供設施。 |
應用程式架構、開發、管理和測試 |
低 |
使用敏捷的開發工具鏈,結合應用程式堆疊執行個體化和銷毀的自動化,以視需要建置測試環境,縮短應用程式開發的前置時間,並消除許多手動測試步驟。 |
安裝和設定應用程式軟體 |
中 |
完整的應用程式堆疊安裝和組態可使用 等服務輕鬆自動化, AWS CloudFormation 並透過使用 輕鬆設定的登陸區域進行簡化 AWS Control Tower。 |
IT 支援 |
中 |
透過使用 Service Catalog 功能進行自助式佈建、增加使用低成本高可用性架構 (減少中斷並設定自動擴展和邊緣運算),來減少 L1 和 L2 支援。 |
資料庫管理 |
最小-低 |
這些活動大部分保持不變。它們通常在 AWS 與內部部署基礎設施相同的層級上獲得資源。 |
基礎設施和安全性需求擷取、分析和設計 |
極小 |
|
文件 |
極小 |
|
應用程式和效能監控 |
極小 |
|
L3 技術支援、回應查詢,以及疑難排解和問題解決 |
極小 |
|
安裝和設定應用程式軟體 |
極小 |
|
應用程式 L3 支援 (預算和長期容量規劃除外) |
極小 |
下表顯示每個工作負載減少層級的預期節省成本。
關卡 |
預期 |
---|---|
非常高 |
85% - 100% |
高 |
60% - 90% |
中 |
30% - 70% |
低 |
10% - 35% |
極小 |
0% - 10% |
這些指標提供評估生產力收益的起點,並將它們包含在詳細的商業案例中。實際的生產力提升會因特定情況而異。計算範圍中點和下端的生產力節省,以估計典型和保守的案例會很有用。
隨著節目的進行,按角色擷取每個活動所花費時間的實際資料非常寶貴。該資料為估計操作建置了改善的基礎,並支援新專案和擴展服務的成本。
外包 IT 操作和支援降低成本
當 IT 營運和支援主要與承包商進行外包或管理時,未來營運模型 (FOM) 的成本分配可以透過向提供受管服務解決方案的 AWS 合作夥伴請求報價來準備,包括 AWS 合作夥伴領導 AWS Managed Services (AMS)
對於詳細的商業案例,根據修訂後的 AWS 服務物料清單和預期的服務使用量、AMS 套件和所需的任何選項,以及所需的服務層級,以引號取代任何基準數字。成本將具有一次性實作元件和以耗用為基礎的執行率。
包含任何剩餘的 IT 操作、必須針對不會遷移到的任何服務保留的支援 AWS,以及如果有任何合約懲罰 (例如,提早終止) 時一次性成本。
開發彈性值模型
在 上 AWS,您可以建構各種高可用性、災難復原和容錯架構。以使用量為基礎的定價表示服務僅在使用時才會收費。這兩個因素共同提供卓越的彈性成本效能。
此外, AWS 客戶也一直使用此功能來改善工作負載的彈性。IDC 2018 年調查
此外,透過現代化應用程式的軟體開發生命週期,實現進一步的彈性。引進具有測試自動化的 CI/CD 管道以支援更高的業務敏捷性時,軟體瑕疵會在開發週期的早期發現,大幅降低軟體維護成本。
若要在商業案例中評估並包含此值,請先與應用程式企業擁有者合作,為要遷移的每個工作負載建立整體利益機會的概觀。 這可能包括下列項目:
-
服務中斷的數量、平均持續時間和性質:
-
服務中斷的範例包括中斷、效能降低、規劃的批次和維護時段過度執行、關鍵函數中的錯誤,以及在尖峰期間存取限流。
-
-
電子商務系統等產生營收的服務中斷對營收的影響:
-
根據中斷時間和交易費率,無法透過服務中斷完成的交易可能數量
-
每個受影響交易的平均值
-
-
與在開發過程中稍早發現生產系統瑕疵的成本相比,支援工程師解決生產系統中瑕疵所需的額外成本
-
影響內部使用者的生產力和損失時間的成本
然後,評估預期且更保守地減少因服務中斷而損失的時間 ,而增加的恢復能力應該產生。例如,請考慮包含下列項目:
-
使用高可用性架構和改善的復原時間目標 (RTO) 和復原點目標 (RPO) 來減少中斷和 MTTR 的數量
-
使用自動擴展等功能,減少減慢速度、消除容量調節和避免批次處理超限
-
透過實作 CI/CD 管道,以及在基礎設施上自動迴歸測試旋轉和向下旋轉,減少僅在生產環境中發現的應用程式錯誤數量,以將成本降至最低
針對要遷移和現代化的應用程式產品組合,將這些項目放在一起,並計算每個案例每年的預期和更保守的商業價值數字。優點應隨著遷移排程而增加,然後根據貢獻應用程式的用量成長預期來擴展磁碟區。
開發業務敏捷性價值模型
業務敏捷性是 AWS 客戶遷移至 的主要原因 AWS。IDC 2018 年客戶調查
準確預測將從任何轉型中累積的所有業務敏捷性優勢具有挑戰性。不過,透過專注於支援大量使用者或業務差異來源的應用程式,您可以將此優勢的重要部分建模並納入基準詳細業務案例。
隨著遷移的進行,隨著更多的效益變得可量化,逐步精簡和擴展業務敏捷性價值模型。這可讓業務案例保持相關性,以便它可以用作引導程式的主要決策支援工具。
若要建置業務敏捷性價值模型,請使用下列指引:
-
選取有機會推動最大業務效能改善的工作負載,例如:
-
產生營收的工作負載
-
業務營運工作負載的範圍,可推動提高效率並從業務中移除成本
-
支援大型使用者群的業務生產力工具
-
-
對於營收和效率產生工作負載,請執行下列動作:
-
對預期主要和次要應用程式升級可推動的營收成長或營運效率進行實際且更保守的評估。
-
估計每年增加的主要和次要版本數量, AWS 以提高應用程式開發速度並縮短基礎設施部署時間。IDC 報告中提供了此項目的一些基準指標。
-
計算實際且更保守的效益期望。在商業案例期間映射它們,在遷移個別工作負載之後,為提升至完全效率提供額度。
-
-
對於業務生產力工具,請執行下列動作:
-
對預期主要和次要應用程式升級可推動的時間節省進行實際且更保守的評估。
-
估計受影響使用者群中人員的時間和精力的平均成本。
-
使用數字來提高主要和次要發行頻率,並計算商業案例期間的效益。
-
由於提高開發人員生產力並縮短啟動時間不需要額外的資源,請將每個工作負載的淨利益行新增至商業案例現金流模型,以包含在折扣的現金流、NPV、ROI、MIRR 和回報計算中。