成功的科技專案，不止於交付

專案完成了。

新系統如期上線，資料移轉順利完成，系統整合正常運作，使用者也完成了教育訓練，整體系統穩定運行。

專案團隊已完成當初承諾交付的所有項目。

按照一般衡量專案的標準來看，這是一個成功的科技專案。

六個月後，有人問了一個不一樣的問題：

「當初我們想改善的事情，真的變好了嗎？」

這個問題，就沒有那麼容易回答了。

這個專案，真正要解決的從來不只是系統

大多數科技專案的開始，都是因為企業希望改變某件事情。

客戶等待的時間太長，員工花太多時間處理人工流程，需要的資訊很難找到，某個流程的成本太高，或是既有系統已經開始限制企業發展。

也可能是企業看見了一個新的機會，卻發現目前的能力根本無法支持。

科技之所以成為解決方案的一部分，是因為我們期待它能讓某件事情變得更好。

但專案一旦開始，大家的注意力很自然地會逐漸轉向：

如何把系統成功交付？

原本的商業問題，開始轉化成需求、時程、預算、系統架構、設計、測試與導入計畫。

這些工作都很重要，也都是成功交付不可或缺的一部分。

但隨著時間過去，大家開始談專案，而不再談當初想解決的問題。

會議討論的是交付日期、缺陷、相依性與上線準備事項；專案報告顯示每一個里程碑究竟是綠燈還是紅燈。

不知不覺間，「成功」也逐漸變成：

能不能把系統順利上線。

然後系統上線了。

大家度過初期難免出現的問題，專案正式宣布完成。

而當初那個促使企業投入這項專案的問題，可能很長一段時間都不會再有人提起。

於是，一家企業可能成功導入了一套全新的客服平台，最後卻發現：

客戶等待服務的時間和以前一樣長。

需要的功能都有，系統效能很好，整合正常運作，員工也知道怎麼使用。

從技術的角度來看，甚至找不到什麼嚴重的問題。

但員工可能在新系統旁邊，又自己做了一份 Excel，因為某件每天都要做的事情，在新系統裡反而很不方便。

大家原本以為可以取得的資訊，真正需要時仍然找不到。原本應該變得更簡單的流程，可能只是換成了另外幾個人工步驟。

科技不需要出問題，一項科技投資仍然可能令人失望。

上線之後，才看得到真實的使用情況

一些最早出現的線索，往往來自使用者自己想出來的替代方法。

有人做了一份 Excel，有人另外維護一份清單。員工開始在不同系統之間複製資料，或者悄悄繼續使用舊有流程的一部分，因為在某些情況下，那樣反而比較好用。

我們很容易把這些現象視為「使用者不願意接受新系統」。

有時候確實如此。人需要時間適應新的科技，教育訓練很重要，而已經習慣多年的工作方式，也不可能一夕之間改變。

但有時候，這些替代方法其實是在告訴我們另一件事。

真正的工作流程，可能和系統設計時大家理解的不太一樣。

員工可能在某個從未預期的時刻，需要某項資訊。會議室裡聽起來完全合理的一項需求，到了星期二早上十點半，當員工真的在面對一位客戶時，可能完全是另一回事。

在系統上線之前，我們對它的許多判斷，其實都建立在預期與假設之上。

我們預期客戶會以某種方式使用它，預期員工會使用某些功能，預期新的流程可以節省時間，也可能因為大家都說需要某項功能，而認為它一定很有價值。

然後，真正的使用者開始使用這套系統。

有些假設被證明是對的，有些則不是。

客戶的行為和我們想像的不同。員工遇到了設計時未曾預料到的例外情況。原本所有人都認為非常重要的功能，幾乎沒有人使用；一個當初看起來不起眼的小功能，反而成了每天不可或缺的工具。

在流程圖上看起來簡單清楚的流程，真正執行之後，才發現裡面充滿各種例外與複雜情況。

這些現象並不一定代表專案做得不好。

它代表企業現在擁有了一樣上線之前沒有的東西：

真實世界的證據。

真正的問題是：還有沒有人在看？

科技團隊很自然地會持續關注可以直接衡量的指標。系統可用性、效能、事件、缺陷、使用量與回應時間，這些都非常重要。

一套不穩定、不可靠的系統，很難真正支持企業的運作。

但這些指標告訴我們的，主要是科技是否正常運作。

它們不一定能告訴我們，當初投入這項科技所希望改善的事情，有沒有真的變好。

一套系統可以達到 99.99% 的可用性，效能表現優異，使用人數也持續增加；同時，原本應該縮短的流程，可能仍然花和以前一樣多的時間。

這兩件事情可以同時成立。

有時候，問題不在科技

科技本身，很少能夠單獨創造企業真正想要的成果。

新系統可能完全按照設計正常運作，但周邊的工作流程並沒有跟著改變。原本不清楚的權責可能仍然不明確，資訊可能依然分散在不同地方，某些政策或規定也可能讓員工無法真正發揮新功能的價值。

甚至，客戶實際的行為可能根本就和當初商業評估時的假設不同。

這並不是說，科技團隊應該為所有的商業成果負責。

科技從來就只是企業想要創造改變的一部分。

如果忽略這個差異，就可能出現一個很奇怪的結果：

每一個人都把自己的工作做好了，但企業最終仍然沒有得到原本想要的成果。

供應商完成交付。

工程團隊完成交付。

專案經理順利結案。

營運團隊正式接手系統。

單獨看每一個環節，好像都成功了。

但回到最初，當初大家真正想改善的事情，可能根本沒有改善多少。

還有一個經常被忽略的因素，就是時間。

即使一項科技專案完全達到了當初的預期成果，企業本身仍然會繼續改變。

客戶需求會改變、業務量會成長，法規與供應商環境會調整，資安威脅也會持續演變。新的科技還會帶來系統設計時根本不存在的可能性。

今天非常適合企業的一套系統，五年後可能成為所有人都在抱怨的那套系統。

這不一定代表當初的決定是錯的。

科技必須存在於一個持續改變的企業之中，而它能否持續創造價值，終究也會面對許多專案開始時無法完全預測的變化與考驗。

系統成功上線，只告訴了我們故事的一部分。

交付之後，才真正看見成果

當一項科技專案真正成功時，關於最初目標的討論，不會隨著專案結案而消失。

系統正式投入使用之後，企業會繼續關注接下來會發生什麼。

使用者自行建立的替代流程，不會一律被視為抗拒改變。有時候，它們反而是在提醒我們，實際情況和當初的預期不一樣。

真實的使用情況，開始告訴我們哪些假設成立，哪些沒有成立。

而當原本預期的改善沒有出現時，討論也不應該只停留在：

「系統有沒有正常運作？」

這並不是要降低成功交付的重要性。

把一項複雜的科技專案真正帶到上線，需要良好的工程能力、跨團隊協作、紀律，以及持續解決問題的能力。

系統必須安全、可靠，並能夠持續維護。專案本身也必須被妥善管理。

這些都非常重要，只是它們並不是「成功」的全部。

專案的終點，和成果的終點，不一定在同一個地方。

成功交付代表企業建立了一項新的能力。

但真正決定這項投資是否成功的，是這項能力投入實際運作之後：

它有沒有帶來當初大家期待的改變？

所以，成功的科技專案不止於交付。

系統上線不是故事的結束，專案結案也不是。

最後真正應該回頭問的，仍然是最初的那個問題：

當初重要到值得我們投入時間、資源與資金去改善的事情，真的變好了嗎？

如果答案是肯定的，

那才是這項科技投資真正的成果。