2026/06/16
圖文引用自：www.cio.com.tw
對許多 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 便成為唯一能承接模糊性的出口。…
