PoC、Pilot、採購、正式導入差在哪？

企業和新創談合作時，最常見的誤會不是技術本身，而是雙方以為自己在談同一件事。企業窗口說「先做個 PoC」，新創聽成「已經有採購機會」；業務單位說「可以 pilot」，法務和採購卻還沒進場；高層說「導入看看」，現場單位才發現沒有預算、人力與維運窗口。PoC、Pilot、採購、正式導入如果沒有分清楚，期待會從第一場會議就開始錯位。

先講結論

這四個詞在會議裡經常被混著用，彷彿是同一件事的四種說法。對財務和法務而言，它們卻是四種完全不同的承諾：一筆可以喊停的實驗費、一筆綁著試運轉責任的費用、一紙有法律效力的商業合約、一項要編年度預算的長期營運承諾。把 Pilot 講成 PoC 的窗口，會讓新創低估投入；把 PoC 講成採購的主管，會在內部簽呈時被財務打回票。名詞用錯，後面整段時程的期待都會錯位。

直接回答

四個階段各回答一個不同的問題。PoC（概念驗證）回答「這個技術在我們的環境裡跑不跑得起來」——小範圍、短期間、用限定資料驗證單一假設，產出是一份結論報告。Pilot（試行）回答「它在真實營運裡撐不撐得住」——真實使用者、真實流量、一段足以暴露問題的試運轉期，產出是導入與否的決策依據。採購回答「我們要不要建立正式商業關係」——走供應商資格、議比價、簽約，產出是一紙合約。正式導入（rollout）回答「全公司怎麼用起來」——部署、資料轉移、教育訓練、維運與續約機制。順序不可顛倒，但每一階段結束都是合法的退出點。

這四個階段最重要的差別，是責任和退出成本逐步上升。PoC 失敗，理論上只代表假設不成立；Pilot 失敗，可能已經影響單一場域或一組真實使用者；採購後退出，要依合約處理；正式導入後再停用，牽涉流程、教育訓練、資料轉移與內部信任。因此，越往後走，越不能只靠口頭興趣推進，必須把結束條件、責任分工與下一步承接人寫清楚。

四個階段，四種承諾

PoC：花小錢買一個答案

概念驗證的本質是買資訊：用幾週到三個月、一個收斂的範圍，驗證「可行或不可行」。它的紀律在於假設要單一、指標要事前寫死、到期要有結論。企業常犯的錯是把 PoC 當成免費試用拖著不結案；比較健康的心態是把它當成一筆研究支出——錢花了，答案拿到，無論答案是Yes還是No都算成功，因為「確定不可行」也省下了後面更大的投資。

Pilot：真實環境的壓力測試

驗證可行之後，Pilot 把方案放進真實營運：真的使用者、真的尖峰流量、真的例外狀況。它要回答的不再是「技術行不行」，而是「營運撐不撐得住」——當機怎麼辦、客訴誰處理、現有系統接不接得上。因此 Pilot 應該付費、應該有服務水準的雛形約定、應該設定試行範圍（一個門市、一條產線）與退場條件。免費的 Pilot 是危險訊號：新創沒有義務為沒收錢的服務扛營運責任。

採購：從實驗關係變成商業關係

採購不是「下單」兩個字，是一整套把交易合規化的程序：供應商登錄與資格審查、規格書、比價或議價、合約條款（含資料、IP、責任、終止）、簽核。對新創方案來說，這一關的特殊之處在於很多制度門檻（資本額、年資、財報）是為成熟供應商設計的，需要提前盤點要不要走例外程序。採購完成的那一刻，雙方的法律關係才正式存在——之前的一切，嚴格說都只是「合作意向」。

正式導入：最貴的不是授權費

導入是把方案變成日常：全面部署、舊資料轉移、全員教育訓練、維運窗口、效益追蹤與續約評估。它的成本結構跟前三個階段完全不同——授權費往往只是一部分，內部的人力、流程改造與轉換成本常常更高。這也是為什麼導入要編年度預算、要有營運單位當主人：它不是專案，是長期營運的一部分。

判斷表

回答的問題	技術可行嗎？	營運撐得住嗎？	要建立商業關係嗎？	全公司怎麼用？
環境	限定資料／沙盒	真實流量、單一場域	—（程序階段）	全面真實環境
常見期間	數週至三個月	一季至半年	視程序，數週至數月	持續性
費用邏輯	小額驗證費	付費＋服務水準雛形	合約價金	年度預算＋內部成本
退出成本	低，到期即止	中，影響單一場域	簽約後受合約拘束	高，涉及轉換成本
結束的產出	簽認的結論報告	導入決策依據	正式合約	維運與續約機制

情境範例

名詞分清楚之後，真正的管理重點是三個轉換點。PoC 到 Pilot：要有人簽字認定驗證達標，並且確認試行的場域與預算已經存在；Pilot 到採購：試行數據要整理成簽呈格式，供應商資格與採購路徑要在這之前就盤點完；採購到導入：合約裡要把導入服務（訓練、轉移、保固）寫成可驗收的項目，不能只買授權。多數案子斷掉的位置不在任何一個階段內部，而在轉換點上沒有人推一把。

舉一個去識別化的情境：某企業窗口和新創完成三週 PoC，技術指標達標，雙方都覺得很順。問題出在下一步，業務單位以為可以直接採購，採購部門卻說供應商資格還沒建立，資安也要求重新評估真實資料環境。結果不是技術失敗，而是 PoC 結束前沒有人同步啟動 Pilot 與採購前置作業。若一開始就把「PoC 達標後由誰開 Pilot 立項會、誰確認場域、誰找採購與資安」寫進結案條件，這個案子就不會卡在成功之後。

常見誤解

「PoC 做得夠久，就可以直接跳到採購。」——再長的概念驗證也不會自動回答營運問題：尖峰負載、例外處理、跨系統整合，都只有真實試行測得出來。跳過 Pilot 省下的時間，常在導入後加倍奉還。

「都叫試用，免費是應該的。」——PoC 小額付費合理，Pilot 免費則不合理：試行階段新創已在承擔準營運責任，沒有對價的責任承諾是空的。企業要的不是省這筆錢，是要對方扛得起服務。

「簽了約就等於導入完成。」——合約只是開始。沒有教育訓練與維運機制，買回來的系統會變成沒有人用的架上軟體，明年續約時才發現使用率是個位數。

讀完後的最小動作

讀完後，企業與新創可以把目前合作放到四個階段之一：PoC、pilot、採購、正式導入。每個階段要回答的問題不同，不要用 PoC 的指標期待採購，也不要用正式導入的責任壓一個還在驗證的案子。

下一步建議

下次開新創合作的內部會議，第一個議程就先對齊：「我們現在講的是四個階段裡的哪一個？」然後檢查兩件事——這個階段的結束條件寫了沒、下一個階段的前置作業（預算、場域、採購諮詢）動了沒。名詞對齊只要五分鐘，卻能避免新創以為在談生意、而你以為在做實驗的雙向誤會。

參考來源與延伸閱讀

FAQ

每個案子都要完整走四個階段嗎？

不一定。技術成熟、市場上已有大量導入案例的方案，可以壓縮甚至跳過 PoC，直接從小範圍 Pilot 開始；反之，愈新的技術、愈核心的流程，愈不該跳關。判斷基準是「不確定性在哪裡」：技術不確定就做 PoC，營運不確定就做 Pilot。

PoC 和 Pilot 可以包在同一份合約裡嗎？

可以，而且常見做法是簽一份兩階段合約：PoC 達標自動觸發 Pilot 條款，含各階段費用與退場條件。好處是省一輪法務來回、給新創可預期性；前提是 PoC 的達標條件要寫得非常明確，否則觸發與否會變成爭議。

Pilot 的合理費用怎麼抓？

常見邏輯有兩種：按正式導入年費的比例折算（試行範圍占全量的比例），或按新創實際投入的人力成本估算。重點不是金額精確，而是費用足以讓雙方認真——企業認真驗收，新創認真維護。

試行結果不錯，但只想維持單一場域使用、不全面導入，可以嗎？

可以，這是合法的決策結果，但要把關係正式化：補一份小範圍的正式合約，含維運與資料條款。最不該的是讓「永久的 Pilot」懸著——沒有合約保護，雙方的權利義務都站不住。