拿SBIR研發補助做軟體委外開發，補助計畫書跟廠商報價常常對不起來

一家經營多年的機械零件商，去年申請到經濟部SBIR一般型補助，準備把內部報價、排程、庫存三套各自為政的Excel整合成一套客製系統。補助核定函下來，裡面寫著三個里程碑：第一期完成系統架構與資料庫設計，第二期完成核心功能並通過內部測試，第三期上線並產出操作手冊。負責人拿著這份核定函去找系統開發廠商報價，廠商給的報價單上寫的是「需求訪談」「UI/UX設計」「後端開發」「QA測試」「上線部署」五個階段，付款比例是30%、30%、20%、20%。

兩份文件擺在一起，負責人才發現問題：補助的里程碑是用來跟政府交代「做到哪一步」，廠商的階段是用來跟客戶交代「錢付到哪一步」，兩套語言完全對不上。補助的第二期要求「核心功能通過內部測試」，但廠商的第二階段只到「後端開發」，測試被排在更後面的QA階段；如果照廠商的付款節奏走，到了補助機關要求繳交第二期成果時，系統可能連測試都還沒開始。這種落差不是哪一方寫錯，而是補助計畫書跟委外合約從一開始就是兩個不同單位、用兩套不同邏輯寫出來的文件，企業主卻要同時對兩邊負責。

補助里程碑跟廠商驗收標準，是兩套不同的語言，簽約前要先對齊

拿補助做委外開發，最容易低估的風險不是廠商會不會做完，而是「做完」這件事在補助機關眼中跟在廠商合約裡的定義不一樣。補助計畫書通常用「功能性指標」或「技術可行性驗證」這類偏向結果導向的語言描述每期要達成什麼，而委外合約的驗收標準如果寫得具體，會落在「某個功能模組能正常運作」「通過某幾項測試案例」這種技術語言。兩者之間需要有人做翻譯，而這個人往往預設是負責人自己，但負責人多半不是技術背景，很難一眼看出里程碑跟驗收項目之間哪裡對不齊。

比較務實的做法，是在簽約前，先把補助核定函或計畫書的里程碑時間表整理成一張簡表，拿給廠商看一次，請廠商直接標註：公司的哪個開發階段、對應補助的哪一期；哪一期的時間點，公司的對應階段還沒開始。這個動作花不到一次會議的時間，但能提前暴露出時間軸錯位的問題，而不是等到補助機關來催繳成果報告時才發現系統進度跟不上。

分階段撥款遇到廠商進度落後，核銷風險跟上線延宕是兩個壓力同時來

多數研發補助採分期撥款，每一期撥款前或撥款後都要求檢附對應的成果證明。如果廠商進度落後，企業主面對的不只是「系統晚上線」這一個問題，而是兩個壓力同時疊加：一邊是補助機關規定的核銷期限，逾期可能影響該期款項撥付甚至整個計畫的後續審查；另一邊是系統本身延宕帶來的營運衝擊，比如原本預計旺季前上線的功能，拖到旺季結束都還沒跑起來。

這兩個壓力同時出現時，企業主很容易陷入兩難：要不要為了趕上補助核銷期限，接受廠商用未完全測試的版本充當「成果」交出去？這種取捨沒有標準答案，但至少應該在簽約階段先想過一次，而不是事到臨頭才倉促決定。具體做法包括：合約裡明訂「里程碑延遲的通知義務」，要求廠商在預估會落後時提前一定天數告知，讓企業主有時間跟補助機關溝通展延或調整成果呈現方式，而不是等到撥款前幾天才發現進度對不上。

核銷需要的文件，簽約前就該講清楚由誰準備

研發補助核銷通常需要一定格式的成果文件，例如系統架構圖、測試報告、操作手冊、甚至部分程式碼或畫面截圖，格式與細節要求因補助類型而異。這些文件如果沒有在合約裡明確約定由廠商負責產出、以補助要求的格式交付，很容易變成廠商做完系統就認為任務結束，企業主才發現自己得另外花時間、甚至另外花錢請人把開發過程重新整理成核銷報告需要的樣子。

補助結束不代表支出結束，維運跟擴充費用要先算進總成本

補助計畫通常只覆蓋開發與驗證階段，系統正式上線後的維運、資安修補、功能擴充，絕大多數不在補助範圍內。不少企業主在評估「這筆補助划不划算」時，只看補助金額跟廠商開發報價的差額，卻沒把補助期滿後每年固定要付的維運費用算進去，結果補助拿到了，系統也做出來了，但隔年才發現維運合約的報價遠超過原本的心理預算，陷入「不續約就等於放棄已經投入的開發成本」的被動處境。

簽約前比較務實的做法，是請廠商把「補助期內的開發報價」跟「補助期滿後的維運報價」分開列出來，即使維運報價只是初估區間，也能讓企業主用補助期加上至少一到兩年維運費用的總成本，去判斷這筆投資是否真的值得，而不是被補助金額的帳面誘因牽著走。

決定申請研發補助做軟體委外開發之前，最後該確認的一件事，是把補助核定函的里程碑表跟廠商報價單的階段表並排檢查一次，找出時間點對不上的地方，並在合約裡加一條廠商配合核銷文件與提前告知延遲的義務條款，這比事後補救要省事得多。