自建還是採購？成本只是決策的一部分

眼前這套商用平台看起來相當不錯。

企業需要的大部分功能都有，導入速度很可能比從頭自行開發快，成本也相對容易預估。

雖然還有一些不足，但一開始看起來似乎都不是太大的問題。

供應商表示，有些問題可以透過系統設定解決，有些可能需要客製化，另外幾項或許可以透過調整現有的作業方式來配合。

直到有人指出：

偏偏其中一項缺少的功能，對企業來說非常重要。

這時候，問題就沒有那麼簡單了。

自行開發可以帶來更大的掌控權，但也代表企業必須在專案結束之後，繼續承擔這套技術所帶來的責任。

採購商用產品，可以把許多責任交給供應商，但企業也因此開始依賴另一家公司的產品、發展方向與決策。

原本看起來只是「授權成本」和「開發成本」之間的比較，到了這裡，其實早已不只是成本問題。

90% 的符合度，真的代表適合嗎？

我們大概都聽過類似的說法：

「這套產品可以滿足我們 90% 的需求。」

聽起來很不錯。

問題是，每一項需求的重要性並不相同。

如果剩下的 10%，都是企業可以接受、甚至根本不需要的功能，那麼這個決定可能很簡單。

但如果那 10% 裡面，包含了企業與競爭對手真正不同的地方、一個員工每天要操作數百次的工作流程，或是客戶真正重視的事情呢？

這時候，90% 這個數字本身，其實已經沒有太大的意義。

這也是為什麼，單看功能比較表很容易產生誤導。

兩套產品可能勾選了差不多數量的功能項目，對企業實際造成的影響卻可能完全不同。

有時候，一套產品「做不到什麼」，比它「能做到多少」更加重要。

面對這些落差，最常見的答案通常是：

「那就客製化。」

先採購產品，再把不符合需求的部分修改到可以使用。

有些情況下，這確實是最合理的做法。

但「客製化就可以解決」這句話背後，可能包含非常不同程度的工作與長期影響。

增加幾個擴充功能是一回事。

在商用產品周圍累積大量客製化的流程、整合與商業邏輯，則完全是另一回事。

尤其當企業不斷修改一套原本就不是為這些需求設計的產品時，很容易增加原本不必要的複雜度。

客製化越多，版本升級越困難，系統整合與維護成本也可能隨之增加。企業甚至會逐漸依賴那些只有自己客製版本才具備的功能與行為。

最後可能出現一個很矛盾的結果：

企業當初選擇採購商用產品，是因為不想自己維護一套客製系統；最後卻為了讓商用產品符合自己的需求，維護了另一套複雜的客製技術。

這並不代表客製化是錯的。

它只是提醒我們：當客製化越來越多，「採購」這兩個字所代表的事情，也就不再那麼單純。

無論自建或採購，都有需要承擔的責任

自行開發有它吸引人的地方，尤其是在現有商用產品無法真正符合需求的情況下。

企業可以掌握要打造什麼、什麼時候改變，以及系統應該如何配合實際的業務運作。在適當的情況下，這樣的掌控權可以帶來很大的價值。

但自行開發，也代表企業必須真正擁有並承擔這套系統的長期責任。

這份責任並不會隨著原始專案結束而消失。

五年之後，原本的工程團隊可能已經有人離開；技術逐漸老化；資安要求不斷改變；而企業也開始需要當初設計系統時根本沒有想過的新能力。

文件逐漸跟不上實際系統；技術需要升級；重要知識逐漸集中在少數幾個人身上。

最後，總有一天可能有人會問：

「為什麼這麼重要的系統，現在卻沒有人敢動？」

今天量身打造的系統，往往就是明天的老舊系統。

採購商用產品，則可以把其中一部分責任交給供應商。

供應商負責維護產品、持續投入研發、維運底層技術，並不斷增加新的能力。某種程度上，這正是企業支付授權與服務費用所換取的價值。

但供應商也有自己的考量與發展方向。

價格會調整，授權模式會改變，功能會改變，公司可能被併購，產品策略與優先順序也可能重新調整。

企業真正需要的某項功能，可能已經被列在明年的產品藍圖上。

也可能永遠不會出現。

與此同時，這套產品也會逐漸深入企業的日常運作。

員工開始熟悉它；作業流程逐漸圍繞著它調整；資料持續累積；其他系統也一個接一個與它整合。

三年之後，「反正不適合還可以換掉」這句話，理論上或許仍然成立。

但真正要換的時候，往往已經不像當初簽約時想得那麼簡單。

所以，無論選擇自建還是採購，都沒有真正消除企業需要承擔的長期責任。

改變的，只是企業選擇承擔哪一種責任。

更難預測的是，企業本身也會改變。

今天做決策時，考慮的是現在的客戶、流程、策略與科技環境。

但企業可能成長、進入新的市場、併購其他公司，也可能徹底改變服務客戶的方式。

今天看起來非常具有差異化的能力，幾年後可能已經成為每一套商用平台都有的標準功能。

反過來，今天看似普通、可以交給供應商處理的能力，未來也可能成為企業非常重要的競爭優勢。

這並不代表我們應該試圖預測所有可能的未來。

如果每一個可能性都要納入考量，決策很快就會變得複雜到根本做不下去。

但接受未來無法完全預測，以及假設企業永遠不會改變，是兩件完全不同的事。

自建或採購，真正重要的是界線畫在哪裡

實際上，大多數企業真正面對的，並不是單純的「全部自己做」或「全部向外採購」。

一套自行開發的應用系統，可能運行在商用雲端平台上，使用託管式資料庫、依賴第三方 API，也可能使用商用 AI 模型與服務。

同樣地，一套採購而來的企業級平台，也可能包含大量為企業量身打造的工作流程、系統整合、擴充功能與商業邏輯。

自建與採購之間的界線，其實很快就會變得模糊。

這不一定是壞事。

它只是代表，真正需要做的決定，往往不是簡單地在「自建」和「採購」之間二選一，而是：

這條界線應該畫在哪裡？

哪些能力重要到值得企業自己掌握？

哪些能力可以放心交由外部供應商提供？

哪些技術與責任，是企業願意長期承擔的？

又有哪些依賴，是企業可以接受的？

這些問題，光靠一張功能比較表或五年的成本試算，很難得到答案。

當這條界線畫得清楚，真正值得企業掌握的能力，可以得到相對應的投入；市場上已經有人做得很好的事情，也不需要只是為了「自己掌控」，而持續消耗有限的工程資源。

企業仍然會有所依賴。重要的是，企業清楚知道自己依賴什麼、為什麼接受這項依賴，以及這項依賴可能帶來什麼影響。

任何選擇都免不了取捨。

真正的差別在於：這些取捨是在做決定時就已經理解並接受，還是在簽完合約、系統也做完之後才發現。

成本當然仍然重要。

授權費用、開發成本、導入成本、營運維護，以及產品上市或投入使用所需要的時間，都應該納入考量。

但最便宜的選擇，可能帶來非常昂貴的限制；最有彈性的選擇，也可能帶來企業根本沒有準備好長期承擔的責任。

功能最多的產品，仍然可能缺少真正重要的能力。

而選擇自己開發，也不代表這項能力自然就具有策略價值。

幾年之後，大概不會有人在意當初那份評估表上最後寫的是「Build」還是「Buy」。

真正重要的是，這套科技是否仍然支持企業的需要、所形成的依賴是否仍然可以管理，以及當企業需要改變時，是否還保有改變的空間。

這或許才是判斷當初是否做了一個好決定，更有意義的標準。