自己開發還是買套裝？中小企業的判斷框架

「我認識一個工程師，他看過我們的流程，說這個他兩三個月就寫得出來。那我幹嘛買現成的？」

這句話我在會議室裡聽過不只一次。講的人通常不是外行，他是真的有在算——他看過 demo、翻過功能清單，覺得套裝軟體有一半的功能他用不到，剩下那一半又不完全符合他家的做法。既然要花錢，那不如找人照自己的流程寫一套，聽起來合理得不得了。

我是熊董，台灣川輝科技。我帶團隊做導入七年，經手 34 個案子、橫跨 12 個產業。這題我被問到麻痺了，所以我把結論先講完：「自建還是外購」這個問法本身就是錯的，因為它預設你要用同一個答案處理整間公司。真正走得下去的公司，都是把系統拆成好幾段之後分別回答的——你的競爭力所在的那一段自己做，跟法規、跟外部標準綁在一起的那一段直接買，剩下的中間地帶用整合把它們接起來。而判斷每一段該自建還是該買，只需要三條軸線：這件事是不是你比同業強的原因、這件事的規則會不會一直變、以及五年後誰負責維護它。第三條最少人問，卻是最後把公司搞死的那一條。因為自建真正貴的地方從來不是開發，是維護——開發是一次性的，維護是每年都要付、而且會隨著時間越來越難付的。

先承認你是對的：套裝軟體確實有一半你用不到

我不打算一開始就說服你別自己做，因為你的觀察是對的。

任何一套賣給整個產業的軟體，本質上都是「一百家公司需求的聯集」。你打開功能選單，看到多國語系、多幣別、多廠區、批號序號雙軌追溯，回頭看看自己公司——一個廠、一種幣別、批號用不到。你覺得自己在為別人的需求買單，這個感覺不是錯覺。

更刺的是另一半。套裝軟體會逼你照它的流程走：它認為報價要先建客戶、客戶要先過信用審核、出貨要先有訂單。但你家的實際做法可能是老闆在 LINE 上跟客戶談完就叫業助先出貨，單子隔週再補。這時候軟體不是在幫你，是在跟你吵架。

所以「我自己做一套完全貼合我流程的」，出發點沒有錯。錯的是它隱含了一個假設：貼合現在的流程，就等於解決了問題。我在現場看到最多的翻車，恰恰是從這個假設開始的。

但這題不是二選一，是「切成幾段分別回答」

先把問題重新問一次。不要問「我該自建還是外購」，要問「我這間公司的哪一段該自建、哪一段該買」。

拿一間做設備代理兼維修的公司當例子。它的日常可以切成幾塊：進銷存與帳務、報價、維修派工與現場回報、保養週期追蹤、對主管機關和稅務端的申報。這幾塊的性質差非常多。帳務和申報那塊，規則是政府定的、每年會改，而且全台灣每家公司都一樣，你在這裡做出任何「特色」都只是麻煩，除了買現成的沒有第二個答案。但維修派工那塊，如果客戶就是因為「叫修當天到、到場前就知道要帶哪個零件」才選它，那一段就是它的命，判斷邏輯不會跟任何一套現成軟體長得一樣。

同一間公司，兩段，兩個答案。

多數人會把它當成單選題，是因為腦袋裡想的是「一套系統」。但你真正需要的不是一套系統，是一組能互通的東西。所以選型時該問的不只是功能清單，還有資料出不出得來、能不能接。

三條軸線：對著每一段流程各問一次

把流程切完之後，每一段拿這三個問題過一遍。問題都很短，但要誠實回答。

第一條：這件事是不是你的競爭力來源。 判斷方法不是你自己覺得，是去問客戶為什麼選你。如果答案是「你們報價快」「你們排程準」「你們願意收零星急單」，那對應的流程就是你的資產，值得自己掌握。如果根本問不出來，那你在那一段沒有任何獨特性，硬要自建只是把同業都有的東西重做一次。我遇到的案子裡，多半的老闆會高估自己流程的獨特性——你以為的「我們做法比較特別」，很多時候只是「我們從來沒有人重新想過這件事」。這兩種不一樣，前者要保留，後者該趁導入時砍掉。

第二條：規則會不會一直變，以及規則是誰定的。 如果規則是外部訂的——稅制、發票格式、電子申報介面、電商平台的 API、主管機關的表單——那你自建等於簽下一份無限期的追趕合約，人家改一次你就得改一次，沒有商量餘地。買現成的，你付的其實是「有人幫你盯著改版」這件事。反過來，如果規則是你自己定、而且你會為了搶生意常常調（折讓怎麼算、業務怎麼抽成、急件怎麼插隊），那買套裝就變成每改一次都要求廠商動一次，久了你會被卡在自己的系統裡。

第三條：五年後誰維護它。 這條我一定會問，而客戶通常會愣一下。不是問現在誰做，是問五年後。你打算自建的那一段，公司裡有沒有人看得懂？是不是只有一個人看得懂？那個人離職、被挖角、或只是想休長假，這段東西還有沒有人敢動？如果答案是「就是那個誰啊」，而那個誰只有一個，你不是在建系統，是在建一顆定時炸彈。

判斷軸線	傾向自建	傾向外購
是不是競爭力來源	客戶說你比同業好的原因就落在這一段	同業做法都差不多，你在這裡沒有特別之處
規則由誰定、變不變	規則你自己定，而且你會為了搶生意常調	規則由外部定（稅務、法規、平台介面）
五年後誰維護	公司內有專職的人，而且不只一個人懂	沒有人專職，換手就沒人敢動

三條軸線不是投票制。第三條有否決權——前兩條再怎麼指向自建，只要第三條答不出來，那段就不該自建。

自建最貴的不是開發，是維護

這是全篇最重要的一段，也是任何一份提案裡都看不到的一段。

開發是一次性的。你談好範圍、找到人、他做完、你驗收，這件事有結束的一天。維護沒有。而維護的負擔不是平的，是隨時間往上爬的，理由有幾個，每一個我都在現場看過。

第一個是寫的人會走。這跟人品無關，工程師的職涯本來就是流動的。他走的時候不會帶走程式碼，但會帶走那些沒寫下來的判斷——為什麼這裡要多一個欄位、為什麼這個狀態不能跳、當初那個奇怪的例外是為了哪個客戶開的。下一個人接手，看到的是一堆能跑但不知道為什麼的邏輯，於是不敢改舊的，在旁邊另外寫一套。兩年後你有兩套做同一件事的邏輯，沒人知道哪套才對。

第二個是底層會老化。系統不是活在真空裡，它踩在作業系統、資料庫、語言版本和一堆第三方套件上面，而這些東西每年都在更新、舊版每年都在被停止支援。你不動它，它自己會壞。要跟上就得有人定期升級，而升級沒有任何看得見的產出，最不容易被排進行程的就是這種工。於是一路拖到不能再拖，最後變成一次大手術。

第三個是需求會一直長，而自建沒有煞車。買現成的要加功能得跟廠商談，這個摩擦力雖然討厭，卻在幫你篩需求。自建沒有這道關卡——業務隨口說一句「能不能多一個欄位」，隔天就加上去了。三年後你會有一張滿是欄位、沒人記得哪些還在用的表單。這種腐爛是無聲的，發現的時候通常已經很難救。

第四個是責任的歸屬變模糊。買來的東西出問題，你可以打電話開案，對方有義務處理。自建的東西出事是自己人扛，而自己人同時還有本業要顧。半夜出貨系統當掉，你要打給誰？這題沒有明確答案，你的自建方案就少了一整塊。

我講這些不是要嚇你別自建，是要你在做決定的那一天把維護算進去。一個誠實的自建決定長這樣：「這一段我自己做，同時我承認我從此每年都要編一筆維護的人力，而且要確保至少有兩個人懂。」這句話你講不出口，答案就已經出來了。

買套裝的代價：你買進的是別人對流程的假設

平衡一下。外購也有代價，只是形狀不一樣。

你買一套系統，同時買進了設計它的人對這個產業的理解：單據該有幾個階段、誰該審核誰、庫存扣減發生在哪個時間點。這些假設有些對你有幫助，那通常是同業長年累積下來的做法，比你土法煉鋼的版本好；有些則會跟你的實際運作正面衝突。

衝突的時候，多數人的直覺是「那就改」。這正是外購最容易失控的地方。改一點還好，改到核心邏輯被翻掉，你會拿到一套外表是套裝、內在是自建的東西——既沒有自建的彈性，又失去外購最重要的價值：升級。這個坑我另外寫過一篇專門講客製化該怎麼踩煞車，這裡只講判準：客製化該花在「你確實比同業強的那一段」，不該花在「我們一直都是這樣做的」那一段。

另一種代價是心理上的。買現成的，你會被迫改掉一部分做事的方法，而這比裝軟體難十倍。這件事沒有捷徑，選自建也躲不掉——自建只是把痛苦延後，變成三年後你發現系統把爛流程完整固化下來了。

什麼情況你兩個都不該做

我願意講這句話：有些公司現在最好的選擇，是兩個都先不要。

如果你連自己的流程怎麼跑都說不清楚——同一件事三個人三種做法、單據欄位每個部門理解不同、庫存數字跟實際盤點永遠對不起來——那不管自建還是外購，都只是把混亂搬到一個更麻煩的地方去。先把流程講到可以畫在一張紙上，再談工具。

另一種是被「免費」兩個字吸引，覺得先弄一套不花錢的來用總不會虧。這個算盤我拆過，免費系統的真實代價通常落在你看不到的地方：資料出不來、沒人負責、出事沒得問。這個邏輯套在自建上一模一樣——找熟人幫忙寫、用人情換來的那套東西，跟免費軟體是同一類風險，共通的問題都是「沒有人有義務在五年後還為它負責」。

所以你明天該做什麼

不要開會討論「我們要不要自己做」。這種會開十次也不會有結論，因為題目本身就錯了。

明天做三件事。第一，拿一張白紙，把公司的日常切成五到八塊，每一塊用一句話寫清楚它在做什麼。不要寫部門名稱，要寫事情——「從客戶問價到報價送出去」比「業務部」有用得多。

第二，對著每一塊各問一次那三個問題：客戶會不會因為這件事選我們、規則是誰在定、五年後誰維護。逐塊寫下答案。你會發現大部分的塊在第一題就出局了，它們既不是你的競爭力、規則也不歸你管，直接歸到外購那堆去，不用再糾結。

第三，把分到「自建」那堆的，再問一個更難的問題：這件事現在誰懂？只有一個人懂嗎？那個人明天遞辭呈會怎樣？答不出來的先移到外購那堆。剩下真的過關的，通常比你一開始想的少很多——而那少少幾塊，才值得你投自己的資源去掌握。

做完這三件事，你手上就不再是「要不要自己做」這個模糊問題，而是一張分好類的清單。清單長什麼樣，答案就長什麼樣。如果切完不確定分類對不對，找個做過幾十家的人陪你走一次，一場免費的三十分鐘診斷通常就夠把方向講清楚。