資訊工程不只是掌握演算法、處理數據的學問
他本質上仍是行為與服務的流程自動化工程
所以要把IT做得好，是有兩個因素的結合
產出效果 = IT技術力 x 現場知識(domain knowledge)
舉例來說，IT技術力強=很會寫程式，演算法工具超多，超會處理資料庫海量數據
但一個IT技術力很強的工程師，突然被派任要去寫台鐵的系統
他根本不知道要寫什麼，因為他對鐵路營運的知識、組織的架構與現況知識零
由於IT技術力很強的工程師，在全世界都是少數、珍貴資源
在官僚化的公家機關、泛國營公股裡更是非常稀缺
所以人事配置一定是：強的IT工程隊「四處征戰」
整團派任到有需求的單位裡，去和現場人員密切溝通
世界各國都是這樣搞的，數位轉型才會成功
採用「開發本部」集中式開發，和現場單位「距離非常遠」的「外包」，
幾乎都會失敗，因為這種溝通的效率很差，很難把需求規格溝通清楚
就像南山人壽之前請德國思愛普軟體SAP開發，SAP根本沒有保險的領域知識
他們兩方溝通又非常不順暢，提出的規格完全搞不清楚
結果花了天文數字的開發費，最後上線史詩級崩潰
再來就是台鐵外包中華電信的票務系統，這是時間長到以十年為單位的開發慘劇
這和台鐵已經是一個慘烈組織，其實連自己都搞不清楚自己的內部資源狀況也有關
而且溝通跨越非常多單位層層交疊，效率極差
回到原題的台灣行政，行政的數位改革不可能是一個天才在自己的辦公室自己發想
他一定需要各部門之間的大量平行溝通，而不是由上而下的垂直溝通與中央統一開發
很多人會誤會IT是一種天才單打獨鬥的領域，實際上IT是與管理學高度掛鉤的團戰
非常講究溝通的質量與密度與頻率
很多人也常笑什麼日本IT數位力很差，實際上台灣也很差，因為規模經濟小，
公務門發包IT又愛搞御三家裙帶閉門造車，台灣IT可能比日本還差
台灣強的是做硬體IT，和我們這裡講的組織流程IT化、軟體層面是兩回事