资讯工程不只是掌握算法、处理数据的学问
他本质上仍是行为与服务的流程自动化工程
所以要把IT做得好，是有两个因素的结合
产出效果 = IT技术力 x 现场知识(domain knowledge)
举例来说，IT技术力强=很会写程式，算法工具超多，超会处理数据库海量数据
但一个IT技术力很强的工程师，突然被派任要去写台铁的系统
他根本不知道要写什么，因为他对铁路营运的知识、组织的架构与现况知识零
由于IT技术力很强的工程师，在全世界都是少数、珍贵资源
在官僚化的公家机关、泛国营公股里更是非常稀缺
所以人事配置一定是：强的IT工程队“四处征战”
整团派任到有需求的单位里，去和现场人员密切沟通
世界各国都是这样搞的，数位转型才会成功
采用“开发本部”集中式开发，和现场单位“距离非常远”的“外包”，
几乎都会失败，因为这种沟通的效率很差，很难把需求规格沟通清楚
就像南山人寿之前请德国思爱普软件SAP开发，SAP根本没有保险的领域知识
他们两方沟通又非常不顺畅，提出的规格完全搞不清楚
结果花了天文数字的开发费，最后上线史诗级崩溃
再来就是台铁外包中华电信的票务系统，这是时间长到以十年为单位的开发惨剧
这和台铁已经是一个惨烈组织，其实连自己都搞不清楚自己的内部资源状况也有关
而且沟通跨越非常多单位层层交叠，效率极差
回到原题的台湾行政，行政的数位改革不可能是一个天才在自己的办公室自己发想
他一定需要各部门之间的大量平行沟通，而不是由上而下的垂直沟通与中央统一开发
很多人会误会IT是一种天才单打独斗的领域，实际上IT是与管理学高度挂钩的团战
非常讲究沟通的质量与密度与频率
很多人也常笑什么日本IT数位力很差，实际上台湾也很差，因为规模经济小，
公务门发包IT又爱搞御三家裙带闭门造车，台湾IT可能比日本还差
台湾强的是做硬件IT，和我们这里讲的组织流程IT化、软件层面是两回事