一套產品要賣給誰，會決定它長什麼樣子，如果使用者是工程師，產品可以從功能開始想，因為工程師知道自己要什麼，也看得懂系統給的答案，但如果使用者是 C-Level，他打開系統的時間可能只有三分鐘，而他要做的是一個牽涉數百萬預算的決定。
LumiTure.ai 是萬里雲把多年 FinOps 顧問經驗產品化的嘗試，而在這個過程中，團隊最先撞上的問題不是技術，而是一個更基本的疑問，一套企業級的產品，到底要依據什麼才算「做好了」？
我們打造的第一版 LumiTure.ai 其實非常簡單，它的工作就是把不同雲端平台的資料收集進來，透過圖表視覺化呈現，讓使用者看見各項成本數據。
不過產品做出來沒多久，團隊內部就出現了不同的聲音，有的質疑很直接「如果只是把資料抓進來做成 Dashboard，那和 Power BI 有什麼差別？」
這個問題不好回答，因為它是對的，市場上能做圖表的工具很多，其中不少是企業本來就有授權、IT 部門也已經熟悉的產品，如果客戶要的只是把成本畫成折線圖，沒有理由為此額外編列一筆採購預算。
更麻煩的是，這個質疑指向的不只是功能，而是開發方式本身，當時產品的推進邏輯，比較接近專案管理的視角，客戶提出需求，團隊做出來就算完成，這套邏輯在顧問服務裡完全行得通，因為每一個專案的邊界都由客戶定義，客戶說可以了就是可以。
但一套要賣給企業的產品沒有這種邊界，需求做完，不等於產品做好，團隊真正缺的，是一個外部的、可以被檢驗的標準，來定義什麼叫做「做完了」。
什麼才叫企業級的成本管理？我們盤點出三個缺口
帶著這個問題，團隊重新盤點了一次產品，結果發現缺口相當明確，而且三個缺口指向的是同一件事。
第一，沒有完整的標籤（Tag）管理。 系統無法回答成本該歸屬給哪個部門、哪個專案。看得到總額，分不出責任，而一筆分不出責任的支出，實務上等於沒有人需要為它負責。
第二，沒有高階主管需要的決策視角。 打開系統的人如果不是工程師，其實看不出所以然，但真正做出預算與投資決策的人，往往不是每天操作系統的人。
第三，沒有依照國際標準設計資料架構。 跨雲之間的成本無法用一致的邏輯比較，多雲整合形同虛設。
三個缺口的共同點是：產品能看到成本，卻還不能回答企業最在意的問題，而它們之所以會同時出現，根本原因是團隊當時沒有一把外部的尺，需求做完就算完成，但需求本身是零散的，零散的需求做再多，也不會自動長成一套完整的產品。
於是團隊做了一個決定：LumiTure.ai 真正要產品化的，不是圖表，而是萬里雲多年來累積的 FinOps 方法論，而要讓方法論站得住腳，必須先找到一個比自己更高的標準。
FOCUS 標準是什麼？為什麼它會決定產品架構？
這件事軟體工程界比較早遇到，一套系統可不可靠，如果沒有事先講定要衡量什麼、以及要好到什麼程度，最後就會變成每個人各憑感覺，工程師覺得沒當機就算穩定，業務覺得客戶沒抱怨就算穩定，主管則要等到出事才知道原來不穩定。
工程團隊的解法是把衡量標準明確寫下來，而且盡量採用領域內共通的定義，而不是每一家自己發明一套，共通的定義帶來一個關鍵好處，就是它可以被外部檢驗，也可以被跨團隊比較。
團隊最後決定，以 FinOps Foundation 推動的 FOCUS（FinOps Open Cost and Usage Specification）作為產品的核心標準，把不同雲端平台的成本資料，轉換成一致的語言，只有先建立共同的資料語言，後續的分析、預測與跨雲比較才有意義。
團隊的開發邏輯也因此反轉過來，不是先想要做什麼功能，而是先確認標準要求什麼，再回頭檢查產品缺了哪一塊。
開發得比較晚，反而成為優勢
有一件事，是團隊做了這個決定之後才慢慢意識到的，市面上許多 FinOps 工具開發的時間更早。在那個時候，FOCUS 標準還沒有出現，各家只能用自己的方式定義成本資料結構，而當時的設計重點多半放在工程端的資源監控，並沒有把管理層的決策需求納入考量。
老實說，我們開始做 LumiTure.ai 起步雖然晚，反而能夠先對齊國際標準，再反過來推導產品架構，而這件事沒有辦法事後補。
資料模型是一套產品的地基，功能可以增加，介面可以重做，但如果底層的成本資料一開始就是用自己的邏輯拆分的，要在上面重建一套符合國際標準的結構，等於整棟拆掉重蓋，這也是為什麼我們堅持標準這件事必須在第一天決定。
依照標準，長出來的三項能力
一、給決策者看的商業洞察
如果今天是一位高階主管打開 LumiTure.ai，他真正想知道的可能不是 CPU 使用率，比較想知道的是：這個月成本分攤狀況？哪一個部門造成影響？哪些投資回報有沒有符合預期？成本預測與實際開支有沒有差距？花費比同業多還是少？
這項能力的重點不是把數據換成另一種圖表，而是協助管理者更快理解成本背後代表的商業意義，把過去需要顧問協助分析的工作，逐漸內建到產品之中，至今，這仍是 LumiTure.ai 最主要的差異優勢。
二、成本預測
在過去的顧問專案裡，企業往往只能在月底收到帳單之後，才知道成本是否超出預算，但事後檢討的價值有限，如果提前知道一些事情，決策方向可能會完全不同，LumiTure.ai 因此開發成本預測功能，除了呈現過往使用的歷史數據，還把預測結果納入預算與營運規劃。
三、成本分攤
這一項最能說明「方法論產品化」究竟是什麼意思，企業導入容器（Container）架構之後，多個部門、多個專案的服務往往共用同一批運算資源，雲端帳單只會顯示這批資源的總額，無法回答每一個部門或專案需要承擔多少。
分不開，就沒有人需要負責，而沒有人負責，浪費也就無從檢討。
LumiTure.ai 能夠計算容器化環境的成本分攤，並據此找出資源優化機會，而這一段，正是許多既有工具還沒有走到的地方，因為它們往往不知道該從哪一個計費環節開始拆。
不過，團隊始終沒有把「功能越多越好」當成產品目標，每增加一項能力，都會回到同一組問題：這是不是客戶真正需要的？是不是能解決企業每天都會遇到的管理問題？是不是符合 FinOps Foundation 所倡導的最佳實務？如果答案是否定的，就不急著放進產品。
當 AI 出現，標準本身也必須演進
就在 LumiTure.ai 逐漸建立起符合企業需求的 FinOps 平台時，市場又迎來另一個轉變，企業開始大量導入大型語言模型，而 AI 的成本，已經不是傳統 FinOps 能夠完整管理的對象。
過去談 FinOps，管理的是虛擬機、儲存空間、容器、資料庫或網路流量，每一項資源都有相對固定的計價方式，也有成熟的最佳實務可以參考。
但在研究國際上關於 AI 成本管理的討論時，有一個觀念對團隊產生很大的影響，如果企業只比較不同模型的單價，很可能會做出錯誤的決策。
因為價格最低，不一定代表成本最低。
一個價格較高的模型，也許一次就能完成任務，另一個價格便宜的模型，卻可能因為品質不足，需要重複執行數十次，最後整體成本反而更高。而這還沒有計入中間耗掉的人工檢查與修正時間。
換句話說，衡量指標必須跟著改變，管理雲端時，企業重視的是資源利用率、成本分攤與預算控制；管理 AI 時，企業更在意的是每一筆支出究竟換到了多少可用的結果。
回顧 LumiTure.ai 的發展歷程，從跨雲成本整合、標準化資料模型，到商業洞察、資源優化、成本預測與成本分攤，每一次演進，都不是單純增加功能，而是回應企業管理方式的改變。
而回到最初那個問題：一家雲端顧問起家的公司，到底為什麼要幫客戶少花雲端的錢？因為在企業真正看清楚自己的科技支出之前，所有關於投資的討論都只是猜測，看得見才談得上判斷，判斷得了投資才會發生。
(本文訊息由 CloudMile 萬里雲提供，內文與標題經 TechOrange 修訂後刊登。新聞稿 / 產品訊息提供，可寄至：[email protected]，經編輯檯審核並評估合宜性後再行刊登。圖片來源：CloudMile 萬里雲。）
