IT委外是什麼？發包前要搞懂的三種模式與費用邏輯

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

「我們想把IT委外出去。」這句話在中小企業裡出現的頻率很高，但如果追問一句「你想委外的是什麼」，答案往往差很多：有的人是想找人固定維護公司的電腦與網路，有的人其實是想做一套系統出來。

這兩件事在中文網路上都被叫做「IT委外」，實際上卻是兩種不同的生意、不同的廠商、不同的計費方式，連合約要注意的重點都不一樣。發包前先把這件事分清楚，比什麼都重要。

IT委外是什麼？它其實包含兩種完全不同的需求

IT委外，簡單說就是把企業內部的資訊相關工作，全部或部分交給外部的專業團隊處理。但「資訊相關工作」這個範圍其實很寬，實務上可以分成兩大類：

第一類：持續性的維運工作。公司的電腦壞了要修、網路不通要處理、伺服器要定期檢查、防毒與備份要有人管、同仁的帳號權限要有人設定。這類需求的特徵是「沒有終點」，只要公司還在運作就會一直需要，通常按月計費。

第二類：把一個東西做出來。公司想要一套內部管理系統、一個官方網站、一支APP，或是把兩套現有系統串接起來。這類需求的特徵是「有明確的完成點」，做完就交付，通常是專案制報價。

多數在網路上談「IT委外」的文章，講的其實是第一類。如果你真正需要的是第二類，看完那些文章去找廠商，很可能會找到不承接開發工作的維運服務商。

先問自己一個問題：你要的是「維運」還是「做一個東西出來」

這是發包前最該先釐清的分歧。一個很常見的狀況是：一間公司的老闆說「我們要IT委外」，找了幾家維運服務商來談，談到一半才發現雙方講的不是同一件事——公司真正想要的是「把現在用Excel管理的訂單流程，做成一套線上系統」，而維運商提供的是設備與網路的月費維護服務，兩邊的需求對不上，來回幾週的時間就這樣浪費掉了。

分辨方法其實很簡單，問自己：這件事做完之後，會不會有一個「東西」交到我手上？

• 會有（一套系統、一個網站、一支APP）→ 你要的是開發委外，該找的是開發團隊。
• 不會，只是讓現有的東西持續正常運作 → 你要的是維運委外，該找的是維運服務商。

有些公司兩種都需要，那就是兩個不同的合約、可能是兩家不同的廠商，不要期待一家全包。會全包的廠商也存在，但要確認他兩邊的能力是否都真的到位，而不是其中一項只是掛著。

三種委外模式，差別在誰負責管理

把需求類型分清楚之後，接下來是委外模式。實務上大致分三種，關鍵差異在於誰指派工作、誰對最後的成果負責：

模式	誰負責管理	計費邏輯	適合情境	變更彈性
人力擴編	客戶自己管	依人力與時間計費	內部有技術主管，只是缺人手	高，可隨需求增減人力
專案委外	廠商負責交付	專案制，依規格報價	要做出一套系統／網站／APP	低，中途改規格成本高
維運託管	廠商負責運作	月費或年費，含服務水準約定	網路、伺服器、設備的持續維護	中，依合約範圍調整

人力擴編是「借人手」：外部的工程師加入你的團隊，工作由你指派、進度由你控管，成果責任仍然留在你這邊。適合公司內部已經有懂技術的主管，只是人力不夠。

專案委外是「交付成果」：你講清楚要什麼，廠商負責規劃、開發、交付一個能用的東西，成果責任在廠商。這是要做系統、網站、APP時最常見的模式，相對的，你對開發過程的介入程度也比前一種低。

維運託管是「託管運作」：廠商負責讓既有的設備與服務持續正常運作，通常會約定回應時間與服務範圍，成果以「有沒有達到約定的服務水準」來認定。

規模稍大、需求比較複雜的公司，實務上也可能同時用上不只一種：例如核心的系統開發用人力擴編、讓自己保有主導權，日常的設備與網路維運則交給維運商按月託管。這種混合做法沒有標準答案，重點是每一塊的責任歸屬要講清楚，不要出事的時候幾邊互推。

費用怎麼算？兩種需求的計費邏輯完全不同

維運類的費用，常見的計價依據包括：要管幾台設備、服務範圍到哪裡、要求多快回應、需不需要到場、有沒有含備份與防護。這類服務多半是月費制，好處是每月支出可預期、方便編預算。

開發類的費用則完全是另一套邏輯：依功能複雜度、規格範圍、開發期程來估算，通常是專案總價，可能分階段付款。這裡有一個中小企業常低估的成本結構——規格範圍才是決定價格的主因，不是「做多久」。同樣是「做一個訂單系統」，只做基本的建檔查詢，跟要串接金流、對接會計系統、還要有權限分級與報表匯出，價格會是完全不同的量級。這個邏輯跟網站設計費用的估算方式是一樣的，範圍決定價格。

也因為這樣，把兩種需求放在一起比價是沒有意義的：一個是持續性的月費，一個是一次性的專案總價，數字本身沒有可比性。

自己請一個IT人員，還是委外？

這是中小企業最常糾結的問題，可以從三個角度判斷：

需求的持續性：如果每天都有大量的IT雜事需要即時處理，養一個內部人員的反應速度確實比較快；如果需求是階段性的，例如今年要建一套系統、之後就是偶爾維護，養一個全職人力的固定成本，會有很長一段時間是閒置的。

技術的廣度：一個人不可能同時精通網路架設、伺服器維護、資料庫、前後端開發、行動APP。中小企業請得起的通常是一位通才，遇到需要專精的工作時仍然要另外找人；委外的好處是可以依當下需求找到對應專長的團隊。

成本的性質：自聘是固定的人事成本，不管當月有沒有事情做都要支出；委外可以把它轉成隨需求變動的支出。這不代表委外一定比較便宜——需求密集時委外未必划算——而是這筆錢的「性質」不同，適合的公司狀態也不同。

實務上很多中小企業採取的是混合做法：內部留一位懂公司狀況、能對內溝通的窗口，專業或階段性的工作再委外，兩邊各自發揮。

合約沒寫清楚，是八成糾紛的起點

業界的普遍觀察是：委外出問題，多數不是廠商技術不行，而是服務範圍一開始就沒講清楚，加上發包時只比最低價。這兩件事往往是同一個問題的兩面——範圍模糊的報價，本來就比較容易報得低。

發包前建議至少把這幾件事寫進合約：

• 服務範圍：哪些事情包含在內、哪些要另外計價。維運看服務項目與回應時間，開發看功能規格清單。
• 變更流程：需求改變時怎麼處理、怎麼計價。這一條在開發專案裡特別重要。
• 驗收標準：什麼狀態算完成。維運看是否達成約定的服務水準，開發看功能是否符合規格。
• 資料與權責：資料的所有權、保密義務，以及萬一出狀況時的責任界線。
• 原始碼與交付物歸屬：這一條值得單獨拉出來講，見下一節。

特別提醒開發類的專案：規格在動工前沒有確認清楚，中途修改需求的成本會明顯高於一開始就談定。三種委外模式裡，專案委外的變更彈性是最低的，因為報價與時程都是照著一開始的規格估的。這不是廠商刁難，是這種合作模式本身的特性。

原始碼歸誰？合約沒寫的話，法律的預設可能跟你想的不一樣

很多企業主會直覺認為「錢是我出的，做出來的東西當然是我的」。在台灣的著作權法底下，這個直覺並不成立。

依著作權法第12條，出資聘請他人完成的著作（委外開發的系統、網站、程式都屬於這一類），如果契約有約定著作財產權歸誰，就依契約；但如果契約沒有約定，著作財產權是歸「受聘人」，也就是開發廠商享有，出資的一方只能在當初出資目的的範圍內利用這個著作。

這條規定的實際後果很具體：合約沒寫清楚的話，日後你想自行修改系統、把原始碼交給另一家廠商接手維護，或是把這套系統改成別的用途，都可能超出「出資目的範圍」而產生爭議。等到真的想換廠商時才發現這件事，處理起來會很被動。

所以發包時務必在合約明確寫出著作財產權的歸屬，要不要連同著作人格權相關的約定一併處理，也可以一起談。這不是不信任廠商，是把日後雙方的權利義務講清楚，對兩邊都好。正派的開發團隊通常不會迴避這個話題。

怎麼判斷這家廠商適不適合你

除了看報價，這幾個面向值得一起評估（如果你要發包的是網站類專案，挑選網頁設計公司的判斷指南裡有更細的評估項目）：

• 他做過類似的東西嗎：不是看案例數量多不多，而是看有沒有處理過跟你類似的問題類型。
• 他問的問題夠不夠深：一個只問「你要幾頁」「預算多少」就報價的廠商，跟一個會反問「你現在這個流程實際上怎麼跑、卡在哪裡」的廠商，後續的落差通常很大。
• 需求還很模糊時，他怎麼反應：多數中小企業第一次發包時，需求本來就講不清楚。願意陪你把模糊的想法拆解成具體規格的廠商，跟要求你「先想清楚再來談」的廠商，適合的對象不一樣。
• 合約條件談不談得開：願不願意把服務範圍、變更流程、著作財產權歸屬白紙黑字寫清楚，是一個很實用的判斷指標。
• 交付之後怎麼辦：系統上線後有沒有維護、保固範圍多久、之後要加功能怎麼算。

如果你正在評估的是「把一個東西做出來」這一類的需求，而不是設備維運，找一個真的在做系統開發的團隊會比較對得上。瞻新資訊的日常工作就是幫客戶把還沒成形的需求拆解清楚、再決定用什麼技術做出來，有需要的話歡迎聊聊你手上的狀況。

FAQ