創新部門怎麼跟業務單位、IT、法務協作？

閱讀提醒：本文是企業開放式創新的一般實務整理，提供協作流程的思考框架，不構成法律、採購、資安或合約建議；不同公司的組織結構、法遵要求與產業規範差異很大，實際的合約條款、資料處理與資安標準應另洽貴公司法務、資安與採購單位，並依個案調整。

跨部門協作會卡關，幾乎都不是因為大家不會溝通——而是因為各部門的誘因結構從一開始就沒對齊，等到問題浮現才協調，往往已經來不及。把這件事想透了，你會發現解法不在「會議開得多勤」，而在「讓對的人在對的時間進場」。這篇文章要拆的，就是業務、IT 資安、法務採購三方各自的誘因，以及怎麼把進場時機往前挪，讓 PoC（Proof of Concept，概念驗證，指用小範圍、限定期間的實測來驗證一個合作或技術假設是否成立）真的跑得完。

如果你在創新部門，最熟悉的痛苦可能是「大家口頭都支持，但每一步都要追」。業務說最近人手不足，IT 說資料不能這樣接，法務說合約版本不對，採購說供應商資格還沒建。這些回覆聽起來像阻力，但多數時候只是組織在用既有風險控管方式處理一個還沒被設計好的創新案。要讓案子往前走，創新部門不能只當活動主辦人，必須提前把每一方的風險、責任與可接受邊界整理成同一張圖。

一個典型的卡關現場

協作失敗最常見的不是吵架，而是時程默默被推遲——以下用一個整季的延遲來說明，實際拖多久因公司流程與案子規模而異，這裡的天數只是把問題講具體，不是普適的基準。設想一個畫面：創新部門花了三個月選出新創、談好 PoC 範圍，合約送出去那天，資安部門第一次聽說這件事，要求補做供應商評估；法務拿出為大型供應商設計的採購合約範本，新創的兩人法務量能根本接不住；業務單位的課長則在 kickoff 會議上才問：「這個測試誰出人力？」三個部門都沒有惡意，每個人都在盡責地做自己該做的事，但 PoC 已經往後推了一季。

之所以要先看這個場景，是因為它把問題的真正位置標出來了。表面上看起來是「溝通沒做好」「通知太晚」，但如果你把每個部門的反應拆開看，會發現他們的行為其實非常理性：資安要求評估、法務拿出範本、業務問人力，這些都是他們的職責所在。問題不在任何一個人身上，而在於這套流程預設了「創新部門先把案子談定、再去找其他部門配合」的順序——而這個順序本身，注定會在最後一刻引爆所有被延後的衝突。要解，就得回到每一方的誘因，看懂他們為什麼會這樣反應。

三方的誘因結構，先看懂再談協作

跨部門協作卡關的根源不是溝通技巧，而是誘因結構：業務單位的 KPI（Key Performance Indicator，關鍵績效指標，指年度被考核的量化目標）是業績，PoC 對他們是額外工作；IT 與資安是出事時的究責對象，天然傾向說不；法務與採購的工具箱是為成熟供應商設計的，套在新創身上就是無限期延遲。把這三方分開講清楚，協作節奏才有著力點。

先看業務單位。業務主管的年度目標裡，從來沒有「配合創新部門」這一項。要他撥出工程師陪新創跑測試、開放真實流程資料，等於是要他用自己的人力與資源，去養一個別人頭上的 KPI——他不配合不是保守，是算得很清楚。所以這裡的關鍵動作只有一個：題目必須從他自己抱怨過的問題裡長出來，而且 PoC 的成功指標要同時掛進他的年度目標。當測試成功省下的是他自己團隊的工時、改善的是他自己產線的良率，人力就不再是要不要給的問題，而是他自己會主動推。反過來說，如果一個業務主管一直「沒空配合」，多數時候那是「這不是我的痛點」的禮貌說法——這時把案子升級到高層去壓，換來的只會是出席率，不會是投入度。與其逼他出席，不如回頭檢查題目來源：題目不是他提的，先換掉的應該是題目本身，而不是再多排幾場會。

再看 IT 與資安。新創的系統要接進內網、要碰客戶資料時，萬一出事，第一個被檢討的是資安主管，不是創新部門。理解這一點，就知道為什麼「最後才通知資安」必然換來「最嚴格的標準」——當一個人只在最後一刻被丟進一個他無法掌握的風險裡，他唯一能保護自己的方式就是說不。比較能運作的做法是把順序反過來：在題目定義階段就請資安一起進來畫邊界——哪些資料可以進沙盒（sandbox，指與正式環境隔離的測試環境，資料外洩或系統出錯都不會波及真實營運）、哪些必須先去識別化、外部系統用什麼方式隔離。先給他畫紅線的權力，他才有空間反過來幫你找一條可行的路。這也是為什麼，當資安要求看起來嚴格到「PoC 根本做不起來」時，真正該換的問題不是「能不能放行」，而是「在什麼邊界內可以做」——去識別化的資料、隔離的環境、限定期間的存取權限，多數驗證題目在縮小範圍後，仍然做得出有效的結論。資安說不的對象，通常是某個過大的範圍，而不是合作本身。

最後是法務與採購，這裡藏著最容易被忽略的隱形成本：範本錯置。多數企業的採購合約，預設對手是一家有完整法務與財務團隊的成熟供應商——百萬保額、近乎無限的賠償上限、數十頁條款。這套範本丟給一家兩人法務量能的新創，對方簽不起也看不完，而來回修改的每一週，都在消耗雙方剛建立起來的合作熱度。解法是預先準備一套 PoC 專用的輕量合約：範圍限定、期間限定、賠償上限對應到這次 PoC 的實際規模而非整份大供應商標準、智財（智慧財產，指 PoC 過程中產生的技術成果、資料與程式碼的歸屬）先講清楚。準備這套範本要花一次力氣，但它省下的，是每個案子重新個案談判的時間，而那是以月計算的。（這類流程錯置正是企業創新最常見的失敗來源之一，延伸見企業創新最常失敗的 5 種原因。）

如果要把三方的進場時機、該問的問題與該避開的動作放在一起對照，下面這張表是整篇文章最值得記住的一頁：

協作對象	你要先問的問題	進場時機	不該做的事
業務單位	題目是他的痛點，還是我替他想的？	選題階段	替業務單位決定他們需要什麼
IT／資安	資料與系統邊界誰來畫？	題目定義階段	合約簽完才送資安評估
法務／採購	有沒有新創專用的合約版本？	PoC 範圍確定時	直接套大型供應商採購範本
高層 sponsor	跨部門僵局出現時誰裁決？	立項時就指定	等卡關了才往上報

這張表的重點不在欄位本身，而在那一欄「進場時機」——你會發現所有有效的進場時機都被往前挪了。事後協調，不如事前設計，整套協作的差別就濃縮在這一句。

可以直接抄的協作節奏

把誘因看懂之後，接下來要落到一套可重複的節奏。一個能跑得完、又不會在中途長出僵局的 PoC，靠的是三場有明確產出的會議，而不是靠頻繁但沒有結論的同步。

第一場是立項對齊會，在 PoC 正式開始前開。業務 owner（負責人，指實際承擔這個題目成敗、會用到成果的那個人）、IT 資安、法務、創新部門四方都要到齊，當場產出一頁文件——寫清楚題目、資料邊界、要用哪個版本的合約、成功指標長什麼樣子、以及 go/no-go（繼續或中止）的決策日期與決策人是誰。這場會的價值不只是對齊，它本身就是一個篩選器：如果這四方根本湊不齊，通常代表這個案子還不該啟動。湊不齊哪一方，就代表那一方的誘因還沒被處理好——業務缺的是痛點、資安缺的是夠早的進場時機、法務缺的是合適的範本。先補誘因，再排會議，順序不能顛倒。

第二場其實是一連串的雙週同步，貫穿整個 PoC 期間。固定十五到三十分鐘，只追三件事：進度對不對得上原訂節奏、有沒有冒出新的資料或權限需求、風險有沒有變化。之所以是雙週而不是月會，是因為一旦拉長到一個月，問題會在兩次會議之間悄悄長成僵局——資料權限卡住、需求變更沒人拍板、風險浮現卻沒人處理，等下次開會時已經積成一團解不開的結。短而密的同步，本質上是在不讓小問題有時間發酵。也正因如此，如果你發現跨部門會議總是在重複討論同一個爭點，原因通常不在會議頻率，而在立項時那頁決策文件根本沒寫清楚——一旦指標、邊界、決策人與日期落成白紙黑字，之後每次爭論都能回到這頁文件，而不是回到各自的記憶與立場；文件不在，會議就會變成立場的循環播放。

第三場是決議會，在 PoC 結束時開。依照立項時就寫好的指標做 go/no-go，而且要由業務 owner 主講，而不是創新部門主講——這個細節很關鍵，因為主講的人就是最終要扛這個結果的人。這裡有一個反直覺但必須記住的判斷：一個沒有結論的 PoC，比一個失敗的 PoC 更傷。失敗至少給了明確答案，而懸而未決的 PoC 消耗掉的是所有部門的信任，下一次你再想找人配合，門檻會高出許多。

同一家公司，兩種創新案

抽象的原則講再多，不如看兩個對照。下面是去識別化的例子，呈現的是兩種協作設計會長出多不一樣的結果。

同一家金融集團裡的兩個創新案。第一個案子由創新部門全程主導，業務單位只在 Demo Day 出席露個臉，PoC 報告寫得很漂亮，簡報也好看，但結案之後，沒有任何一個業務單位願意編預算把它承接下去——因為從頭到尾，這都是創新部門的案子，不是任何業務單位自己的案子。第二個案子的起點完全不同：它從消金部門一位協理抱怨對帳流程太花人力開始，創新部門只做了三件事——找到三家能解這題的新創、先帶資安把資料邊界畫好、把輕量合約準備到位。PoC 由消金部門自己驗收，而隔年的導入預算，也順理成章編在消金部門自己的帳上。

值得玩味的是，第二種案子裡，創新部門的存在感看起來反而比較低——沒有主導、沒有搶下 Demo Day 的鎂光燈。但只有這一種案子能被複製，因為它把成果的所有權交還給了真正會用它的人。第一種案子的漂亮，是創新部門自己的漂亮；第二種案子的低調，才是整個組織學會了一次怎麼跟外部新創協作。這個對照其實也回答了一個更根本的問題——企業為什麼要費這麼大力氣跟新創合作（這個前提見企業為什麼需要新創合作？）：不是為了辦一場好看的 Demo Day，而是為了讓某個業務單位真的把一個外部解法用起來、並且願意自己掏預算養下去。

判斷順序

跨部門創新最容易卡住的地方，不是大家不支持，而是每個人支持的層次不同。創新團隊支持探索，事業單位支持有用，IT 與資安支持可控，法務與採購支持可承擔；如果這些支持沒有被翻成各自的責任，專案就會在最後一哩路散掉。因此真正要管理的不是會議出席名單，而是每個部門承接哪一種風險。

讀完後的最小動作

讀完後，創新團隊可以先列一張內部角色表：事業單位負責需求、IT 或資安負責系統邊界、法務負責合約、採購負責付款路徑、財務負責預算。若其中任何一格沒有 owner，專案不是不能開始，而是要先承認那一格就是未來最可能卡住的地方。

帶走的判斷

如果這篇文章只留下一件可以馬上做的事，那就是：挑一個你手上正要啟動的合作案，現在就檢查立項對齊會的四方名單，能不能在兩週內湊齊。湊不齊哪一方，那一方就是你這個案子真正的風險所在——而你該補的是那一方的誘因，不是那一方的出席率。業務缺痛點，就回去把題目換成他自己抱怨過的事；資安缺進場時機，就把他從合約後移到題目定義階段；法務缺範本，就先花一次力氣把 PoC 輕量合約備好。

也要誠實面對這套方法的邊界。它不是萬靈丹，遇到真正的部門本位主義或資源緊縮，再好的協作設計也會被現實磨損；而最該避開的一個捷徑，是用「高層支持」去壓過部門的異議、強行啟動——高層的壓力壓得過一次 kickoff，壓不過接下來六個月的消極配合。跨部門協作真正的成果，從來不是一場準時開的會、也不是一份漂亮的結案報告，而是讓對的部門在對的時間進場，最後願意把這個外部解法當成自己的事承接下去。那一刻，創新部門才算真的把協作這件事做成了。

關於本文與來源

本文為台大創創中心依企業開放式創新的一般實務整理而成，未引用特定外部研究或報告，所述協作流程、合約與資安做法均為通則性的經驗歸納，僅供思考框架參考。不同公司的組織結構、產業規範與法遵要求差異甚大，實際導入時的合約條款、資料處理與資安標準應另洽貴公司法務、資安與採購單位確認，並依個案調整。

延伸閱讀

• 企業與 CVC 學習路徑
• 企業創新基本功
• 企業為什麼需要新創合作？
• 開放式創新、加速器、CVC、創新競賽差在哪？
• 企業創新最常失敗的 5 種原因
• 企業合作與 CVC