合理化數字資產
雲端合理化是評估資產以判斷在雲端中裝載資產的最佳方法的程式。 在您判斷 方法 並匯總 清查之後，就可以開始雲端合理化。 雲端合理化討論最常見的合理化選項。
觀看下列影片，以快速概觀完成完整的評量，以協助您規劃並排定移轉工作的優先順序。
傳統合理化觀點
當您將傳統的合理化程式可視化為複雜的判定樹時，很容易理解合理化。 數字資產中的每個資產都會通過一個過程來提供，這會產生五個答案之一（合理化的五個 Rs）。 對於小型莊園，此程序運作良好。 對於較大的資產而言，效率低下，可能會導致顯著的延遲。 讓我們檢查程式以瞭解原因。 然後，我們將呈現更有效率的模型。
清查： 使用傳統模型完成完整合理化所需的資產清查，包括應用程式、軟體、硬體、操作系統和系統效能計量。
量化分析： 在判定樹中，量化問題驅動第一層決策。 常見問題包括下列各項：
- 目前使用中的資產嗎？
- 如果是，它會正確優化並調整大小嗎？
- 資產之間有哪些相依性？ 這些問題對於庫存分類至關重要。
定性分析： 下一組決策需要以質化分析的形式進行人類智力。 通常，這裡提出的問題對解決方案而言是獨一無二的，而且只能由商務項目關係人和進階使用者回答。 這些決策通常會延遲此程式，大幅降低速度。 此分析通常會在每個應用程式耗用 40 到 80 FTE 小時。
如需建置定性分析問題清單的指引，請參閱 數位資產規劃方法。
合理化決策： 在經驗豐富的合理化小組手中，質化和量化數據創造了明確的決策。 可惜的是，具有高度合理化經驗的小組需要耗費大量資源來僱用或花費數月時間進行訓練。
企業級合理化
如果這項工作對於 50 個 VM 數字資產而言相當耗時且令人生畏，想像一下在具有數千部 VM 和數百個應用程式的環境中推動商務轉型所需的工作。 所需的人力工作很容易超過1,500 FTE小時和9個月的規劃。
雖然完全合理化是最終狀態和前進的好方向，但它很少產生高ROI（投資報酬率），相對於所需的時間和精力。
當合理化對於財務決策至關重要時，值得考慮一個專門從事雲端合理化的專業服務組織來加速此程式。 即便如此，完全合理化可能是延遲轉換或業務成果的昂貴且耗時的工作。
本文的其餘部分說明另一種方法，稱為累加式合理化。
累加式合理化
大型數字資產的完整合理化很容易面臨風險，而且可能會因為複雜度而遭受延遲。 累加方法背後的假設是延遲決策會讓企業負載錯開，以減少障礙的風險。 經過一段時間，這種方法會建立有機模型，以開發更有效率地制定合格合理化決策所需的流程和經驗。
清查：減少探索數據點
很少有組織投資時間、精力和費用來維護完整數位資產的準確即時清查。 遺失、竊取、重新整理週期和員工上線通常會證明使用者裝置的詳細資產追蹤是正當的。 在傳統內部部署數據中心維護精確伺服器和應用程式清查的ROI通常很低。 大部分的 IT 組織都有比追蹤數據中心內固定資產使用量更緊迫的問題。
在雲端轉換中，清查會直接與營運成本相互關聯。 正確規劃時需要精確的清查數據。 不幸的是，目前的環境掃描選項可能會將決策延遲數周或數月。 幸運的是，一些技巧可以加速數據收集。
代理程式型掃描是最常引用的延遲。 傳統合理化所需的強固數據通常只能透過在每個資產上執行的代理程式收集。 這種對代理程式的相依性通常會讓進度變慢，因為它可能需要安全性、作業和管理功能的意見反應。
在累加式合理化程式中，無代理程式解決方案可用於初始探索，以加速早期決策。 視環境中的複雜度層級而定，仍可能需要代理程式型解決方案，但可以從業務變更的重要路徑中移除。
量化分析：簡化決策
不論清查探索的方法為何，量化分析都可以推動初始決策和假設。 當嘗試識別第一個工作負載或合理化的目標是高階成本比較時，這尤其如此。 在累加式合理化程式中，雲端策略小組和雲端採用小組會將五個合理化 Rs 限制為兩個簡潔的決策，並只套用這些量化因素。 這樣可簡化分析，並減少驅動變更所需的初始數據量。
例如，如果組織正在將 IaaS 移轉至雲端，您可以假設大部分的工作負載都會淘汰或重新裝載。
定性分析：暫時性假設
藉由減少潛在結果的數目，更容易達成有關資產未來狀態的初始決策。 當您減少選項時，也會降低此早期階段商務詢問的問題數目。
例如，如果選項僅限於重新裝載或淘汰，則企業在初始合理化期間只需要回答一個問題，也就是是否要淘汰資產。
「分析建議沒有任何用戶主動使用此資產。 這是準確的，還是我們忽略了一些東西？這類二進位問題通常更容易透過定性分析來執行。
這種簡化的方法會產生基準、財務計劃、策略和方向。 在稍後的活動中，每個資產都會經歷進一步合理化和定性分析，以評估其他選項。 您在此初始合理化中所做的所有假設都會在移轉個別工作負載之前進行測試。
挑戰假設
上一節的結果是一個粗略的合理化，充滿了假設。 接下來，是時候挑戰其中一些假設了。
淘汰資產
在傳統的內部部署環境中，裝載小型、未使用的資產很少會對年度成本造成重大影響。 除了一些例外狀況外，分析並淘汰實際資產所需的 FTE 工作，超過了剪除和淘汰這些資產所節省的成本。
當您移至雲端會計模型時，淘汰資產可大幅節省年度營運成本和預先移轉工作。
組織完成量化分析后，淘汰 20% 或更多數字資產並不罕見。 建議您先進行進一步的定性分析，再採取行動。 確認之後，淘汰這些資產可能會產生雲端移轉的第一個 ROI 勝利。 這通常是最大的成本節約因素之一。 因此，雲端策略小組應同時監督資產的驗證和淘汰，同時執行 Migrate 方法，以達成早期財務勝利。
程序調整
一家公司很少只踏上一次轉型之旅。 成本降低、市場成長和新營收流之間的選擇很少是二元決策。 因此，我們建議雲端策略小組與IT合作，以識別主要轉換旅程範圍內平行轉換工作的資產。
在本文中提供的 IaaS 移轉範例中：
要求 DevOps 小組識別已屬於部署自動化一部分的資產，並從核心移轉計劃中移除這些資產。
要求數據和 R&D 小組識別為新營收串流提供動力的資產，並從核心移轉計劃中移除它們。
此以程式為主的定性分析可以快速執行，並建立多個移轉待辦專案之間的對齊方式。
您可能仍然需要將某些資產視為重新裝載資產一段時間。 您可以在初始移轉之後逐步進行合理化。
選取第一個工作負載
實作第一個工作負載是測試和學習的關鍵。 這是展示和建立成長思維的第一個機會。
商務準則
若要確保業務透明度，請識別雲端策略小組業務單位成員所支援的工作負載。 最好選擇一個小組有既得的賭注和強大的動機移至雲端。
技術準則
選取具有最低相依性的工作負載，並可以移動為一小組資產。 建議您選取具有已定義測試路徑的工作負載，讓驗證更容易。
第一個工作負載通常會部署在實驗環境中，而不需要操作或治理容量。 請務必選取不會與安全數據互動的工作負載。
定性分析
雲端採用小組和雲端策略小組可以共同分析此小型工作負載。 此共同作業會建立受控的機會，以建立及測試定性分析準則。 較小的人口有機會調查受影響的使用者，並在一周內完成詳細的定性分析。 如需常見的定性分析因素，請參閱合理化五 個 Rs 中的特定合理化目標。
遷移
在持續合理化的同時，雲端採用小組可以開始移轉小型工作負載，以在下列主要區域中擴充學習：
- 使用雲端提供者的平台加強技能。
- 定義符合長期願景所需的核心服務和 Azure 標準。
- 進一步瞭解作業在轉換稍後可能需要變更的方式。
- 瞭解任何固有的商業風險，以及企業對這些風險承受能力。
- 根據企業的風險承受能力，建立治理的基準或最低可行產品 （MVP）。
版本規劃
雖然雲端採用小組正在執行第一個工作負載的移轉或實作，但雲端策略小組可以開始將其餘應用程式和工作負載的優先順序設定為優先順序。
電源 10
傳統的合理化方法會嘗試滿足所有可預見的需求。 所幸，要開始進行一個轉型程序，通常不需要為每個應用程式設定一個計劃。 在累加模型中，Power of 10 方法提供良好的起點。 在此模型中，雲端策略小組會選取要移轉的前10個應用程式。 這十個工作負載應該包含簡單和複雜的工作負載混合。
建置第一個待辦專案
雲端採用小組和雲端策略小組可以共同處理前 10 個工作負載的質化分析。 此工作會建立第一個優先順序的移轉待辦專案，以及第一個優先發行待辦專案。 此方法可讓小組反覆運算方法，並提供足夠的時間來建立適當的程式以進行定性分析。
讓程式成熟
在兩個小組就定性分析準則達成一致之後，評估可能會成為每個反覆專案內的工作。 就評估準則達成共識通常需要兩到三個版本。
在評估進入移轉的累加執行程序之後，雲端採用小組可以更快速地逐一查看評量和架構。 在這個階段，雲端策略小組也會抽象化，以減少其時間的流失。 這也可讓雲端策略小組專注於將尚未在特定版本中的應用程式排定優先順序，確保與不斷變化的市場狀況緊密配合。
並非所有排定優先順序的應用程式都已準備好進行移轉。 當小組進行更深入的定性分析，並探索可能會提示重新排列待辦專案的商業事件和相依性時，排序可能會變更。 某些版本可能會將少數工作負載分組在一起。 其他可能只包含單一工作負載。
雲端採用小組可能會執行不會產生完整工作負載移轉的反覆專案。 工作負載越小，相依性越少，工作負載就越可能適合單一短期衝刺或反覆專案。 基於這個理由，我們建議發行待辦專案中的前幾個應用程式很小，而且包含少數外部相依性。
結束狀態
一段時間后，雲端採用小組和雲端策略小組會共同完成清查的完整合理化。 這個累加方法可讓小組在合理化程序中持續更快。 它也有助於轉型旅程，以更快產生有形的業務結果，而不需要那麼多的前期分析工作。
在某些情況下，財務模型可能太緊，無法做出決策，而不需要額外的合理化。 在這種情況下，您可能需要更傳統的合理化方法。
下一步
合理化工作的輸出是受所選轉換影響之所有資產的優先順序待辦專案。 此待辦專案現已準備好作為雲端服務成本模型的基礎。