對資訊系統發展的幾點省思
現今對軟體（資訊系統）的分類大抵可分為三類：(1)嵌入型軟體（Embedded Software），通常是指嵌入在硬體設備中的軟體，比如家電、汽車控制系統、醫療設備等；(2)產品型軟體（Software Product），就是通用的，滿足一般性需求，針對大眾市場的軟體，比如 Office、Photoshop等，這類軟體的功能通常是標準化的，藉由販售授權或訂閱等方式盈利； (3)客製型軟體（Taylor-made Software System），指根據特定客戶需求定製的軟體，比如企業內部的ERP系統，或者政府機構處理業務的資訊系統（例如公文管理系統、疾病通報系統等），這類軟體是為特定使用者或組織開發的，滿足個別的需求，通常不會在市場上公開銷售。1
本文係基於個人過往工作經驗上的一些觀察及省思，主要聚焦在客製型軟體，特別是公務機關的資訊系統。雖然現行有些公務機關會採用所謂的「公版」資訊系統（類似產品型軟體，例如差勤系統等），但大多數仍得委託該系統的原開發廠商，根據該機關特殊的需求再客製一番，有時候客製的規模，幾乎與新開發不相上下。此外，有些私人企業在導入 ERP 系統，或是所謂的企業資訊系統時，也會有類似情況，容或可類比參考。至於其他二類軟體，由於銷售、盈利模式，及生產邊際成本不同，其考量重點或思考角度有所差異，不在討論範圍。
過於複雜，必須追求簡單
複雜是資訊系統失敗的主要風險。不論是組織整體的資訊系統架構，或是特定用途的資訊系統，如何應用電腦及網路技術的特性， 簡化、改造、甚至是重新設計現有的作業流程，這樣才能發揮資訊技術的效益。
我們現在看到的公務機關的資訊系統，大部分只是將傳統的人工作業方式，搬到電腦或網路環境。例如電子公文系統，其實是一種「擬紙化」的作法，大家都要在電腦上看到和紙本公文相似的畫面（要有紅色的職名章圖像、依規定方式排列、要有「騎縫章」、還要有「裝釘線」……），除了部分傳遞過程用到網路外，基本上只能算是一種「表單印刷機」。其他類型的系統也相去不遠，2021年 COVID 疫情期間發生的「校正回歸」，據稱就是因為「……通報程序又太繁瑣，導致案件『塞車』；…通報系統太複雜、自動化檢查太嚴格…」2，而這些系統大多是各機關委託廠商，依照其「業務需求」所客製而成的。
造成資訊系統在流程、功能、界面等難以簡化的原因，大多由於業務單位不肯放棄現有的作業流程和作事方法、不肯和其他單位共享資料等（最常抬出法規來當理由），有時候為了展現業績，甚或是「刷存在感」，可能還增添原本不存在或不必要的工作。其次，資訊單位或委外廠商為了配合使用者的這種「想像式」的需求，硬是用軟體去「刻」一些極其複雜且徒勞無功的功能。再者，基於「無限上綱式」的資安要求，不僅造成系統複雜繁瑣，而且耗費資源。舉例來說，現在公文系統在內部線上簽核過程，要求以實體的電子憑證加簽，就有點類似「拿銀行保管箱來放衛生紙」的思維和作法，因為就某些公文的資產價值而言，要達到「不可否認性」的效果，可以有更簡省的方式，而強以實體電子憑證作為加簽工具，未必符合風險管理的原則和建置資訊系統的效益。
要讓資訊系統變「簡單」並不是件簡單的事。首先可能要盤點和檢視現行法規所造成的障礙和壁壘。坦白說，很多現行與資訊作業有關的規範多是「程序和形式」，對數位文件的意義不大。例如，電子公文還要有「騎縫章」？或是公文歸檔的分類方式還要照案、卷、目…層層堆疊？如果這些規範不大幅調整，甚或是打掉重練的話，很難讓資訊系統變得簡單。包括現行的公文程式條例、檔案管理法、文書及檔案管理電腦化作業規範、電子簽章法、甚至資安法等，都應該通盤重新思考調整，如此資訊系統才有可能改頭換面。
簡言之，如果導入資訊技術不能有效地簡化現有的作業流程和作事的方法（破壞式創新？），那就別提什麼數位轉型了（可能轉頭都很難）。我相信在公部門資訊單位「第一線實作」的同仁，都應該很有感觸，如果沒有以簡化為前題，資訊系統談什麼韌性、敏捷這些都只是空話。
刻板僵化，必須追求彈性
首先是系統發展方式的彈性（或是多樣性，並不單是指軟體開發過程的敏捷方法）， 為什麼現在公部門開發資訊系統的時程需要那麼長？
現行公部門建置資訊系統大多從單體式（monolithic）角度思考，也就是將所有可能會用到的功能，鉅細靡遺地都納為系統範圍，如此一來，不僅造成系統擁腫，開發時程加長，後續變更或調整更是困難。 加上依規定外包給廠商承作，從規格研擬、招標、履約到測試驗收，即使再簡單的系統，三、五個月跑不掉，時間都耗在行政程序。持平而論，過往數十年推行資訊系統專案委外的政策，著實應該重新省思。國外有研究指出，這種基於公共行政所謂「新公共管理」原則所倡導委外政策，是導致電子化政府失敗的主因之一。3
……委辦評選，當然有其需要，也是目前採購主流，但也造成公務員逐漸缺乏實際執行經驗。自己動手做跟眼看別人做，對該項業務掌握度絕對不能相提並論，業務無法深入掌握，就難以在原基礎上創新，這或許是政府採購大量委外的未來隱憂吧。
張炎銘，《委員，您好》聯合報(2025-07-26)
其次，資訊系統應該掌握80/20原則，將80%的資源聚焦在20%經常會用到的功能，其他不常用到的功能，不一定要納入系統，將原有單體式的架構改成微服務（microservices）的架構（必須在系統建置前就這樣的思考及規劃，要將運行中的單體式系統改為微服務，實務上極為困難）。某些業務單位常用的「資料彙整性」工作，不見得需要建置系統（因為這類需求經常變動），可以思考導入其他工具，例如，部署機器人流程自動化（RPA）軟體，由業務單位運用這些工具自行處理（類似 end user computing 概念）。
再者，系統操作維運（或是部署）應更具彈性。雲端運算已經是業界主流的系統部署方式，但在公部門的選擇郤極為有限，多數還是放在中華電信或國內業者的平臺。對於某些性質的資料系統或服務（例如，一般訊息的網站、發布新聞的網站），是否一定還要執著於「資料落地」這種不切實際的資安錯覺，值得思考。
盲從務虛，必須追求務實
最沒意義的事，就是努力以更有效率的方式，去做根本不該做的事。（Nothing is less productive than to make more efficient what should not be done at all.）
彼得．杜拉克（Peter Drucker ）
某件事究竟「該不該作」，通常取決於主事者（長官或主管？）的主觀價值判斷。但就資訊系統的建置與否，或該具備那些功能，單就其被利用的頻率和潛在的效益而言，應當要有務實的客觀標準。
令人悲傷的案例：2024年勞動部發生職場霸凌，導致吳姓公務員輕生的悲劇。根據勞動部的調查報告摘述：「客觀來說……吳員所負責之『智能就服專案』就算再怎麼努力，也很難完成謝員之要求」「其規劃內容僅與現在的就業 e 點靈類似，不夠智能，恐無法符合謝員之要求……」4
那麼「謝員之要求」究竟是什麼呢？為什麼會作不出來？
報告指出：「無人知曉謝員指示之具體內容及需求為何，於相關主管及資訊人員之訪談中，皆無人能具體言說所謂『智能就服專案』實質內涵」
「智能就業服務系統」就是「配對系統」的一種而已，是全球應用排名前三的系統之一，範例何止千萬，是大學生的基礎習題，哪需要龐大工作量？所謂「做不出來」，應是「智能」二字無法迎合主管的想像。
吳統雄，《輕生案反映「AI內閣」的蹭紅務虛》聯合報(2024-11-23)
誠哉斯言。此案例的關鍵就在於無法滿足長官的「科技幻想」，也就是源自於「蹭紅務虛」的價值取向。如果「智能就服專案」連需求都說不清楚（甚至是講不出來），那客觀來說，豈不就是「根本不該作的事」嗎？
調查報告另提及「資訊系統之建置分工，需先有業務單位提出之明確業務需求，資訊人員方能據以落實系統開發及建置事宜」。但有時候就算業務單位講得出需求，資訊系統也不見得作的出來。舉例來說，有業務單位提出需求：同一文號的公文，在同一時間，其密等可以即是「密件」，又是「普通件」（有點類似說，同一身分證號碼的自然人，其性別在同一時間，即是男的，又是女的）；還有對已經存查或發文的公文，要求能「死而復活」，繼續用同一文號簽核公文……。這類需求，不只是該不該作的問題，實際上是能不能作的邏輯問題（同一命題，不能同時即為真，又為假）。這些在實務上都曾發生，業務單位甚至主張「我們只負責提出需求，資訊單位就應該設法滿足這些需求。」
任何組織在作一件事之前，應該思考這件事是真得有必要作？如果真有必要作，是不是一定要建置資訊系統來作（說不定別的方式更好）？如果一定要建置資訊系統來作，是否已經想好流程要讓系統怎麼作？如果想好系統怎麼作，有沒有想過現在的資訊技術能不能作？如果現在技術可以作，要花多少成本才能作？平心而論，現今公部門普遍存在目標毫不明確的系統或是網站，這些系統或網站利用率極低，甚至沒有人用（比如先前各機關爭相發展各種APP, 但下載數量卻少得可憐）。從工程經濟的角度看，任何非必要或是無用的功能，不但增加成本，還會增加系統發生錯誤的機率，甚至增加資安的風險。
勞動部的調查報告另有：「近年來資安議題發酵，法規要求日益嚴格，相關措施及行政作業大增…」「關係人甲除資訊工作，尚必須兼辦諸多資訊安全工作，更加重其工作負擔…」。5其實，現今這種情況在公務機關甚是普遍，而所謂的「資訊安全工作」，如果就資安法所規定的「應辦事項」，率多屬行政作業（寫計畫、填報表、辦稽核），而這些究竟是不是「該作的事」，恐怕值得反思。因為這類的應辦事項，能否具體的減少資安風險，只怕主管機關不見得說得清楚。
結語 - 管中窺豹？
布魯克斯（Frederick Brooks, Jr. 1931-2022）在上世紀所著的《人月神話》（The Mythical Man-Month: Essays on Software Engineering），至今仍可視作是軟體開發的經典著作。他認為軟體開發的根本困難在於「概念的複雜性」(conceptual complexity)，而軟體專案負責人最重要的職責，就是與客戶一同探索，從混亂的需求中提煉出一個優雅、一致、且具有核心價值（=簡單、彈性、務實??）的系統概念。
這要如何具體實踐呢？首先，要勇敢地對提出需求者（業務單位、客戶、使用者）說「不」。但並非單純的拒絕，而是引導他們分辨「必要的核心功能」(must-have)與「想要的」、「有了也不錯的附加功能」(nice-to-have)。這樣才能避免系統中存在某些無用的、無效的、甚至是幻想式的功能，導致系統紊亂複雜，難以運行。 其次， 要持續聚焦探究「為何」(Focus on the Why)，而非糾結在「如何」（How to）滿足需求。 舉例來說，當業務單位提出需求：我想要列印出這種報表、那種報表……而且還要隨時可以調整報表內的數據、表頭的日期也要能修改…… ，先不要立刻去想如何實作這些報表，要先反問：「您為什麼需要這些報表？您想用它來解決什麼問題？」也許深入了解後會發現，業務單位只是「需要將報表簽陳給長官核閱」。如些來看，一個匯出 Excel 的按鈕，也許會比許多報表選單更實際些。再進一步探究，這些報表究竟有沒有需要紙本陳核？說不定長官可以透過查詢界面，就獲得相同的訊息（可能更即時），或是由系統定時以郵件通知，這樣可能連匯出 Excel 的功能都不需要，會不會是更好的解決方案。但不可諱言，經過持續探究後，業務單位極可能會「抗拒」這樣的改變（錢塘江水工症群？） 。這種情況，就超出資訊系統發展或設計原則的討論範疇， 也不是資訊單位或軟體專案負責人所能單獨應對， 宜由組織中更高的管理或領導階層參與處理，就整體評估後作出價值的判斷與取捨。
注釋及參考資料
Fernandes, João M., and Ricardo J. Machado. 2016. Requirements in Engineering Projects. Lecture Notes in Management and Industrial Engineering. Cham: Springer International Publishing.↩︎
中央社，3天前發現通報數有異 陳時中曝「校正回歸」始末https://www.cna.com.tw/news/firstnews/202105220220.aspx↩︎
Waller, Paul, and V. Weerakkody. 2016. “Digital Government: Overcoming the Systemic Failure of Transformation. Digital Transformation through Policy Design with ICT-Enhanced Instruments.” SSRN Electronic Journal. Elsevier BV.↩︎