FinOps的採用
建立Finops實踐就是在組織內建立共識
FinOps是一個持續不斷的活動，一切都是為了往完美接近，但卻又永遠無法到達完美。但FinOps的從業者如何讓大老闆或客戶買單FinOps呢?
本文將介紹一些常用的方法，如何讓C-Level的長官們買單，特別是CFO/CIO/CTO等。沒有這些C-Level的支持，我們的FinOps可能會因為企業的其他優先考量而卡在FinOps只做到一半。本文也探討了 FinOps 驅動者的流程，FinOps 驅動者認知到這種實踐的必要性並在企業內部倡導它。
下圖概述我們幫助在企業中建立實踐和文化時需要了解的關鍵人物角色和需要完成的里程碑。
在我們開始對C-Level推銷FinOps之前，我們要真實的檢視企業已經有哪些FinOps的活動了。因為這些活動是在企業的雲端採用旅程緊密相連並且最積極地優先考量哪些成果。
FinOps 不是為了省錢，而是透過基於數據的雲端技術投資決策來賺錢。 如果我們的首要任務是盡快離開地端機房，或利用雲端來改造我們的技術並增加營收，那麼我們可能不會獲得大量支援來專注於具有長尾效應的業務； 我們只會有加速雲端遷移的支援。
不同的C-Level有不同的推銷法
為了確保推銷成功，讓我們再次討論本部落格中介紹的 FinOps 成熟度模型。在早期階段，我們將根據希望實現的成果進行一定的宣傳。 為此，我們必須評估企業的實際情況。 在不早期的階段，我們可能會做與 FinOps 相關的事情，例如審查支出或偶爾進行優化，但這不是在生命週期中執行這些操作，也不是運行FinOps框架(具有FinOps能力，或採用腳本)。
推銷說帖
當我們開始要對C-Level推行FinOps時，一定是有些問題我們會被問到的。不過一開始的簡報可貼上巴菲特的名言:"聰明人開始做的事，傻子最後才跟進"。
第一題:為什麼我們(公司)要推行FinOps?
Ans: 這一題可以參考本部落格"甚麼是FinOps"一文與相關文章。但可以簡單總結: 讓公司知道公司投資的每一塊錢所帶來的商業價值。
第二題: 對每個參與其中的C-Level們有什麼效益？
Ans: 每個C-Level的關注點（和利益）都不同。 如果個別高階主管了解具體細節，這將有助於他們建立自己的案例來支持該方案。 在本文後面，我們將詳細分析CEO、CFO、CTO等之間的個人高階主管挑戰、動機和利益。
第三題:就雲端採用而言，公司將獲得哪些效益以及將獲得哪些成果？
Ans: 主要成果可以參閱本部落格的"FinOps框架"一文。同時也要仔細檢視我們的雲端採用成熟度，以確定成本分配、最佳化等優勢之間的平衡。關於雲端採用成熟度可參閱本部格雲端採用系列文章，同時參閱雲端單位經濟一文。
第四題: FinOps 如何幫助暢通資安、GreenOps和永續發展等其他重要措施的道路？
Ans: GreenOps 和 FinOps 團隊之間有強烈的重疊。 他們有著一系列共同的基本目標。 將永續發展目標與 FinOps 連結起來可以幫助滿足外部股東的要求。
第五題: 為什麼現有公司的財務框架沒辦解決雲端方面的財務管理?
Ans: 現有的 IT 財務框架通常與 FinOps 實踐並行作業，解決業務中的不同需求。當公司遇到那些更熟悉傳統 IT 框架但不習慣處理巨大變化的人時，找到這個問題的答案非常重要以及雲端獨有的大規模費用支出資料的細緻度。
由於這還是推銷階段，C-Level可能沒興趣了解太多細節問題。像是FinOps的框架中有甚麼內容。我們應該更具焦C-Level對於使用雲端所產生的問題來進行回答。像是，公司真的知道在雲端上的每一塊成本是怎麼花的嗎?我們怎麼辨識不影響現有業務與系統的情況下進行成本優化呢?而這些是傳統資地端機房在購買軟硬體之後需要做的事。
進階的推銷
不過當公司的雲端使用經驗有一段時間，並且做到某些FinOps知情階段的活動時，推銷的內容就需要稍微升級一些。
比較簡單的方法是，根據FinOps框架中的個別技能能力來辨識公司哪方面還可以更加強進化。也就是推行FinOps可以讓我們在雲端的使用效能做得更好。此階段的推廣重點在於如何增加對特定領域的投資，以實現公司期望實現的特定成果。
下表中的每項能力都應該有一個成功的衡量標準和一組結果，這在FinOps框架文章中有更詳細的介紹，有興趣的讀者可以參閱。但重點是如何實現我們需要達到的目標衡量標準的成功結果。 然後將這些結果與企業實現這些結果所需的要求連結起來，例如：
- 其他團隊的時間承諾
- 額外花費的錢或預先支付的款項
- 增加 FinOps 團隊本身或組織內其他團隊的人數
以下是我們可能希望透過在實踐中進行額外投資來強調的能力成果的一些範例：
成本分配 —
提高成本能正確分配到每個Cost Center的百分比
費用預估 —
加強可靠度與預測能力之類等
量測單位成本 —
辨識可以開始衡量一組產品的業務價值指標並將其與報告連結起來以在雲端財務管理會議中使用的團隊
預算管理 —
提高維持在預估預算範圍內和「左移(shift left)」主動預算管理的能力，以便技術團隊主動預測變更的成本影響，並在預計產生重大影響時提高預算負責人的意識
這一些能力不只是雲端成本的良好管理，同時也帶來了工程效能。例如，這些方式可以讓工程師不會因為雲端財務管理的種種限制陷入困境還能提高發布速度？因為良好的財務管理可以讓業務/產品/技術團隊在雲端上進行更多的實驗與創新。
FinOps 可以提供企業中需要解決的大量問題。 每個都會有所不同。 整個情況可能會影響企業決定投資的內容。每一個角色透過FinOps可以解決的問題有:
- 業務主管 — 利用雲端強化公司的競爭力
- 技術主管 — 創新，同時提高成本效能和交付速度
- 財務主管 — 準確地"理解、分配和預測"雲端成本
以上這些其實都有某些對雲端費用節省有一定的關注，但有不一樣的動機。
FinOps團隊需要多少人呢?
其實就看公司大小與組織架構了。但有一些基本角色則是一定需要的:
- 資料工程師
- 資料分析師
- 自動化工程師
- 主管
對主要贊助者(C-Level)的推銷
雖然要說服一堆C-Level們，但我們還是要找一個C-Level來主推FinOps。大部分會是CIO/CTO，但是也有可能對CFO(尤其如果CEO代兼的話)。這包括涵蓋現有的報告可見度以及根據 FinOps 框架的關鍵功能評估公司的成熟度。 我們可以從 FinOps 基金會網站上提供的開源 FinOps 評估開始。
最重要的是，我們需要說明一旦實施下一階段的實踐，公司文化和作業方式會發生哪些變化。這非常重要，因為文化的轉變需要所有公司高階主管的身體力行。
以下是一些我們針對主要贊者可能會問的問題:
- 工程師的日常作業有何變化？
- 組織需要引進哪些計劃和儀式？
- 技術經理如何開始考量 FinOps？
- 組織如何確保他們擁有正確的資源？
- 如果深入挖掘可見性優勢，企業可以推動哪些單位經濟效益和報告？
以下是一些開始模擬一些特定場景的問題：
- 公司應該計劃以何種組合來實現成本規避(Cost Avoidance)：更多地聚焦減少使用量還是更多地關聚焦降低費率？
- 如果公司有更多的時間和人員來專注於正確維護它們，那麼公司還可以擁有多少個 SP 或 CUD？
- 如果公司能夠更有效地管理雲端資源批發價和資源利用，那麼去年公司可以省多少？
- 公司需要改變什麼，以便一年後回顧時，效率顯著提升？
- 如果有整個公司的目標或對此類變革有更好的C-Level們的支持，那麼他們可以減少多少使用量？
推銷內容應該涵蓋對公司的真正意義(Big Picture)。 而不僅僅是涉及費用、需要的員工數量以及省的多少錢。這是關於對公司內每個團隊使用FinOps的影響的評估考量，而些在是進入我們推動的"省錢和效率"的價值主張之前。
說服公司內各方的利害關係人
既然要在公司內推行FinOps，哪麼一定有很多受影響的人需要我們去說明或解釋並且取得他們的認可或同意，這樣才可以繼續玩下去。
以下根據這些利害關係人的目標、關注點、關鍵訊息和有用的 KPI 描述了每個C-Level角色。 透過了解每個C-Level的動機，FinOps 推行者將能夠更有效地描述 FinOps 的價值，最大限度地減少獲得所有老闆們的支持所需要的時間和精力。
下圖呈現了 FinOps 驅動者最初如何位於所有不同利害關係人之間，幫助轉換需求並建立橋樑，使他們能夠更緊密地自主合作。
CEO通常關注的是雲端投資能否與公司的業務目標是一致的。下表是一些範例。
CIO/CTO考量的是利用科技為企業提供市場和競爭優勢。
CFO想要的是能提高關於雲端的成本報告和預測的準確性和可預測性。
技術主管聚焦的是提高交付速度，同時保持成本效益並支持創新。
路線圖
成功搞定各方人馬之後，接下來就是開始計畫怎麼逐步推行FinOps了。最容易做的就是建立FinOps路線圖。
第一階段:規劃企業內的 FinOps
此階段的目標是為企業中的 FinOps 轉型制定合適的計劃，該計劃已確認可用的資源以及概述的最重要的目標。有了C-Level們的背書之後，以下是我們可以採取的一些步驟:
- 使用定制的 FinOps 介紹平台或有針對性的問題與他們進行一對一對話，以確定採用策略。
- 研究企業在對話期間遇到的痛點，例如雲端成本破壞商業論證、成本超支的普遍看法、雲端使用者缺乏成本可見度等。
- 研究在你們的談話中影響了團體、團隊和個人。 誰受到痛點的影響？
再來就是建立計畫，基本上就是As-is 與To-be。這應該會吸引公司（由於雲端技術的估值、單位經濟效益的改善等而加速業務）。以下是我們可以採取的步驟:
- 確任工具需求。 確定現有的工具是否可以滿足計劃的要求。
- 確定 FinOps 職能團隊的歸屬。 這可能是在 CCoE、財務或 IT 單位。 根據公司組織結構的複雜性，建立專門的 FinOps 團隊可能會採取分階段的方法。 一些組公司可能
(1) 建立跨職能轉型計畫辦公室並建立作業流程/工作小組，
(2) 建立FinOps 職能作為擴展雲端業務辦公室/CCoE 的一部分，以及
(3) 發展成為專用的雲端 FinOps團隊。 - 辨識可以成為傳教士的候選早期採用者團隊。
- 確定 KPI 來衡量 FinOps 功能，並確定衡量業務部門和開發團隊等利害關係人的參與度和績效的方法。 這些 KPI 是初步的，將在第二階段不斷發展，但有起始設定很重要。
- 準備將在第二階段使用的溝通計劃。
第二階段:將FinOps內化在公司內
FinOps是一種文化的轉變，這需要公司很多人的配合，尤其是C-Level們的身體力行。這一階段的目標就是將第一階段所制定的東西內化在所有相關的利害關係人中。以下的 FinOps Pitch Deck有助於以清晰、易於閱讀和快速的方式傳達這一點。
傳達價值
主要的利害關係人如何在公司內推動FinOps:
- 傳達變革的核心價值
- 分享我們對未來組織的看法的簡短摘要
- 分享高階路線圖
接下來我們會收到各個團隊主管給我們(FinOps)的回饋。因為我們有對這些受影響的團隊個別開會，這可以讓他們:
- 了解 FinOps 是什麼。
- 了解他們的問題並解釋/教育 FinOps 如何幫助他們。
- 討論提議的 KPI 並根據對話回饋進行調整。
- 在 FinOps 和關鍵合作夥伴（IT 、controller、開發團隊）之間建立互動模型。
- 在 CCoE 和執行指導委員會的社交活動中確定未來的成員。
接下來就可以定義初始的FinOps模型。這個模型應該包含資源、運作模式與跨職能互動模式，還有相關的KPI來回報FinOps的進展:
- 為企業客製化 FinOps 模型（知情、優化和維運）。
- 確定具有內部調動且與現有角色或個人重疊的 FinOps 團隊； 透過招募/外包來補人。
- 繪製整個公司（發起者、影響者、採用者）FinOps 的變革網路。
- 制定明確的訓練和溝通策略，確保全面涵蓋所有受影響的資源。
- 建立一個hub-and-spoken 模型，以在超大型企業內擴展 FinOps。
- KPI 路線圖：最終確定第一版的 KPI 和報告，並確定和規劃下一版 KPI 和報告。
第三階段:為 Finops 做好組織準備
這是評估和參與業務各個部分的工作。 此階段的目標是開始在公司內中啟動 FinOps 飛輪，以便我們可以開始在 FinOps 框架的各種功能和領域中的成熟度。
第一步:評估FinOps的就緒
對企業的FinOps關鍵能力成熟度進行評估，這通常包括以下內容：
- 定義Tag/metadata/組織分類法
- 佈署、配置與smoke-test其工具
- 完成第一版 KPI。 KPI/業務採用指標可以在「採用期」中不斷發展，以創造一種成熟度逐漸提高的 FinOps 心態，而不是一次到位。 這樣可以讓成熟度不高的團隊和C-Level不至於被“嚇跑”，按部就班地去做。
- 定義告警和報告限制的使用和支出閾值。
- 定義並準備基於角色的自助服務儀表板。 這些應該顯示重要的指標，例如第一版的 KPI、成本分配、預算異常、優化建議以及其他利害關係人想要看的東西。
- 準備包含單位成本計算的預測模型。 此時，這可能只是一個電子表格。
第二步:讓利害關係人參與
我們現在準備好要實行模型的節奏與流程:
- 確定業務部門對批發價水準的偏好（企業折扣談判的總成本、RI/SP/CUD/等）。
- 讓早期採用者團隊參與以獲得初步成果（例如，關閉不再使用的測試環境或instance以呈現省錢）。 這些對於以後對其他團隊的社交、推廣和贏得更多採用非常重要。
- 獲得一些額外的早期治理成果，以實施 FinOps（例如，標記政策、從租賃到使用的自動化等）。
- 開始定期會議的節奏。 FinOps/CCoE 團隊應定期與業務部門、開發團隊、從業者和利害關係人進行對話，以實施最佳實踐並追蹤 KPI。
但如果公司大到有一堆團隊，每個團隊的FinOps可能有不同的成熟度與雲端運行模式。重要的是，變革管理人員必須考慮到這一點並允許他們以不同的步伐進行採用。
FinOps團隊的類型
這通常有三種:中心化、去中心化與hub-spoken，但這些類型都有其優缺點。
中心化FinOps 團隊可以直接與 CIO、CFO 或 CTO 回報，並充當一種企業服務 — Cloud Finance management as a service。 他們可能是 CCoE 的一部分，也可能不是，如果公司沒有 CCoE。 在雲端花錢的業務部門與這個專門的 FinOps 團隊互動，在 FinOps 活動上進行協作，並且專門的 FinOps 團隊集中了功能（例如管理批發折扣），這些功能從中心化團隊中受益最多。
優點: 有權威、專業知識、規模經濟
缺點: 需要搞定一堆利害關係人，賦能和教育是關鍵，高階主管的支持是必要的
一個中心化的FinOps團隊負責管理批發價並匯總各個團隊的預測等能力，但每個主要業務部門還擁有由各自業務部門資助的專門嵌入的 FinOps 專家。
全職、兼職，還是單次性的Finosp團隊?
FinOps 團隊的資源最終應該1.)完全致力於 FinOps； 然而，團隊通常也以2.)一條帶有回報虛線(一定的作業時間)開始。 以上這兩種模式的組合也很常見：公司有一位專門的 FinOps 領導者，他向財務或技術團隊回報(一種矩陣式的組織架構)。
一開始對FinOps毫無經驗的企業可以借助外部廠商或顧問來進行此一文化的推動。因為一開始企業可能沒有相關的FinOps人才可供協助，畢竟目前市面上這一類的人很少。
企業通常一開始的作法是一種兼職的FinOps團隊，各部門的專家分配初一定的工作時間來協助此一作業。一旦有了成功的運轉經驗與良好的績效，公司才有可能再加碼其資源進到FinOps。
但是，如果我們的FinOps提案遭到拒絕(公司沒有想要做這件事)，會發生什麼情況？ 這時候就要看公司為何做出這樣的選擇了。 這可能是“深口袋症候群”，其中的首要任務是不惜一切代價進行雲端遷移，而C-Level們希望團隊首先擔心的是如何完成遷移。 在這種情況下，我們需要看時機，直到業務準備就緒並開始向各個利害關係人提供可見性，或者是雲端帳單讓老闆嚇一大跳。 這時的時間就會很好，畢竟有些人就是要看到實際狀況發生才會有所反應，而不願先去應對可能發生的風險。
結論
企業採用 FinOps 需要仔細規劃、了解C-Level們的動機以及對企業如何運作進行大量研究。總結一下本文的重點:
- 進階實踐的推銷應包括對當前實踐的評估以及企業內的 FinOps 計劃，其中包括將加速特定能力及其最終結果的額外投資。
- 不要試圖超出最初的 FinOps 實踐計劃。 從小地方做起，做出成績，並隨著時間的推移進行迭代。
- 不同的主管會從 FinOps 實踐中尋求不同的結果； 在推銷之前一定要了解他們不同的動機。
- 在啟動 FinOps 實踐時應重點關注透過謹慎投資即可實現的容易實現的目標(因為一旦沒成績就沒有後續)。
- 請記住在各個階段充分溝通和社交化我們的成績(進行大外宣)，以吸引各個利害關係人的參與。
有一點要記住，建立 FinOps 實踐就是建立共識。 我們必須贏得人心，並改變長期既有的流程。這其實就是改變企業的文化，而這需要企業的所有C-Level的參與跟身體力行。
