數位專案的頻繁失控，往往並非源自技術能力不足，而是組織在不自覺中，將「尚未想清楚的決策」轉嫁給執行端。本文指出此結構性問題，並提出一個「三角色治理」架構，說明頂尖數位原生企業如何避免讓 IT 為尚未完成的決策承擔後果。
文／林華庭（聯新國際醫療集團總執辦策略總監）
對許多 CIO 而言，最熟悉、也最無力的挫敗時刻，往往不是系統上線失敗，也不是資安事件爆發或系統當機，而是一個看似理所當然的管理場景。會議即將結束，決策者語帶保留地表示方向尚未完全釐清，接著把目光轉向 IT，用一種近乎謙遜的語氣說：「這件事我還沒有完全想清楚，你們找時間來訪談我，把需求整理出來。」在多數組織中，這句話常被視為合作的開始，甚至被解讀為對 IT 專業的信任，卻很少有人意識到，它同時完成了一次關鍵而危險的責任轉移。
當失敗被歸咎於 IT，真正的問題早已被錯置
這種錯位之所以特別危險，在於它極度隱性。一旦 IT 開始替尚未成熟的構想補齊邏輯、填補空白，專案表面上得以推進，治理卻已悄然失守。表面上，專案順利啟動，里程碑被排定，組織看似行動迅速；實際上，關於問題本身的定義、取捨與邊界，卻從未真正完成。當尚未完成的決策被直接轉化為已啟動的數位專案，數位治理其實已經在那一刻退場。在這樣的狀態下，組織默認 IT 將為不確定性承擔後果。 IT 被要求提供時程、估算成本、承諾成果，所承擔的已不只是執行風險，而是策略不確定性的延伸。
[ 加入 CIO Taiwan 官方 LINE、Facebook 與 LinkedIn，與全球 CIO 同步獲取精華見解 ]
從那一刻起， IT 不再只是執行者，而被推向一個模糊的位置：既被要求不要介入策略判斷，卻又必須在缺乏明確前提的情況下承諾結果。當結果未如預期，失敗往往被歸咎於執行問題，而不是回頭檢視，是否在一開始就把尚未完成的決策責任，轉嫁給了必須交付的體系。這正是為何數位專案經常陷入「做中想清楚」的惡性循環。需求在專案初期模糊不清，卻仍被要求先行動；等到業務方向逐漸明朗，系統卻已部分成形，任何修正都變成昂貴的變更。越是跨部門、跨系統、跨組織的專案，這種風險就越被放大，而 IT 也成為承接所有模糊性的出口。
世界級案例的教訓
加拿大 Target Canada 的 ERP 導入案，在三年內耗資超過七十億美元，最終不僅未能支撐營運，反而直接導致整個加拿大事業體關閉。初期輿論多將失敗歸因於資料品質、系統複雜度或執行能力，但事後檢討顯示，真正的關鍵問題在於商業模式與供應鏈設計尚未穩定，就要求 IT 建構高度整合的系統架構。需求仍在變動，卻被迫提前制度化， IT 成為承接所有不確定性的出口。
類似的治理錯位也出現在公共部門。美國聯邦政府的 Healthcare.gov 在 2013 年上線初期嚴重當機，首月僅有極少數使用者能成功完成註冊。後續調查指出，政策規則在系統開發期間仍持續變動，但 IT 團隊卻被要求在固定期限內交付完整平台。當政策設計尚未定型，卻要求技術端負責「整合完成」，結果便是系統層面承擔了原本屬於決策層的模糊與矛盾。
雙邊專案的結構性陷阱
許多企業在啟動數位專案時，常常在第一天就做出了一個關鍵卻未被意識到的治理選擇：專案被設計為需求方與 IT 的雙邊關係。一端提出需求，另一端負責交付。表面上，這樣的分工清楚有效；實際上，它隱含了一個幾乎從未被驗證的前提，也就是需求在被提出的那一刻，已經具備足夠成熟度，足以進入執行流程。
現實卻恰恰相反。在轉型情境中，需求往往只是方向性想法、初步假設，甚至是多方妥協的暫時結果。問題並不在於需求不存在，而在於它尚未完成被界定與被承擔的過程。然而，在雙邊結構中，並不存在任何角色專責處理「需求尚未成熟」這個狀態。於是，這個空缺自然落到 IT 身上。這正是雙邊結構最危險的地方。它讓組織誤以為需求是一個可直接翻譯的輸入，而不是需要被設計、被取捨、被否決的決策產物。當需求仍然模糊，卻被要求進入系統建置， IT 便成為唯一能承接模糊性的出口。
為什麼施工單位不負責設計
對 CIO 而言，問題的解法不在於再增加一層流程或工具，而在於重新配置角色責任。組織需要一個能承接「尚未成熟」狀態的角色，確保在進入交付之前，該被想清楚、被取捨、被承擔的事情，真的已經完成。唯有如此， IT 才能專注於交付已被界定的成果，而不是為前端的不確定性買單。
對比建築業，沒有建設公司會在屋主未決定用途與預算前就動工，更不會期待施工單位透過訪談替屋主「想清楚」設計。建築業之所以能運作，關鍵在於「設計者」與「施工者」的嚴格分工：設計者負責界定問題、提出方案並承擔取捨後果；施工者只對已完成的設計負責交付品質。數位專案長期忽略這個原則，部分源自歷史慣性。當系統開始跨部門、跨事業體，需求早已不只是功能清單，而是牽動流程、權責與資源配置的治理議題。此時仍要求 IT 同時扮演設計者與施工者，其實是在把策略性決策責任，隱性地外包給執行端。
三角色接力棒治理模型
在這樣的背景下，三角色接力棒治理模型的意義便變得清楚。決策者的責任，是界定問題方向並承擔策略取捨；第三角色負責需求設計與成熟度檢核，確保尚未完成的決策不會誤入交付；IT 則專注於已定需求的實作與交付品質。
圖一所強調的，不是角色之間的距離，而是責任的接續關係。只有當前一棒真正完成，後一棒才被允許起跑。第三角色的存在，正是為了承接決策尚未完成的狀態，避免模糊被錯誤地包裝成需求。
- 決策者（Decision Owner）：定義方向，承擔策略取捨。
- 第三角色（Requirement Architect）：負責需求設計與成熟度檢核，阻擋未定決策進入交付。
- IT（Delivery Owner）：專注於實作已定需求，確保品質與速度。
進階視角：從接力棒模式走向融合治理
在最頂尖的高度數位化的企業中， IT 不再只是專案末端的交付者，而是逐步轉型為賦能者。技術團隊會更早介入決策討論，提供即時的技術可行性評估，協助決策者理解哪些構想在現階段可行、哪些仍屬於想像。這種提前介入，並不是替決策者做取捨，而是為決策畫出現實邊界。
圖二呈現的是一種建立在治理底線之上的演化型態。IT 轉型為賦能者，透過「技術可行性諮詢」提前介入決策；第三角色則在 AI 輔助下，快速生成原型以釐清需求。
結語：未來 CIO 的角色轉換，不是更懂技術，而是更懂治理
未來 CIO 的角色轉換，一方面必須保護 IT 團隊，不被迫為尚未完成的決策承擔後果；另一方面，也必須確保組織在進入交付之前，已經完成必要的問題界定與取捨承擔。如果「誰在想、誰在設計、誰在做」三件事被混為一談，治理失靈也就成為必然結果。
因此，未來 CIO 最關鍵的能力之一，在於是否有勇氣在關鍵時刻說出「現在還不能承諾」，要求組織先把該想清楚的事情想清楚。這樣的 CIO，並不是阻礙轉型，而是在為轉型建立可持續的基礎。
※誌謝：本文之核心論點與策略視角，承蒙聯新國際醫療集團策略長蔡義昌博士提供實務洞察與寶貴建議，特此致謝。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
