我們看到在系統開發工作上，大家都殫精竭慮，忙了很久時間，但結果卻總是吃力不討好，「做甲流汗，嫌甲流瀾」，而且就算好不容易系統開發好了，驗收了，業務單位也願意使用了，還沒功德圓滿，使用者對於功能及穩定性的抱怨，系統維護、功能新增等問題接踵而至，每一個系統開發案的產生，幾乎就是在IT部門身上增加一個無法解脫掉的負擔，這些負擔隨著各項電子化政府措施的推動而越發沈重，但是在各單位資訊人力無法作相對增加的情況下，大家就好像在作土木結構的壓力測試一般，不斷擠壓檢驗著雙方資訊人員忍受的極限在那裡，以下就謹就個人所見的問題列舉如下，並以個人服務地點為例，說明臺北縣政府在解決這些問題上的構想及作法。
一、需求的多變及理解差距
在政府機關的系統開發標案中，最受廠商垢病但又敢怒不敢言的現象，就是系統需求的一變再變，不僅不同部門、不同人對於同一件事的看法南轅北轍，同一個人在不同時間點的要求也會不同，經過承辦人確認的結果，到了上層主管處可以全然推翻，驗收前、驗收時與驗收後，原有需求都可能變化或產生新的需求，如果碰到承辦人或主管換人，對不起，一切重新開始，「系統開發唯一不變的事就是變本身」，這種狀況就好像建一棟房子，?有藍圖或有藍圖但僅供參考，每一個住戶都可以表示意見，都可以站在自己最關切的角度指揮施工，而建築公司因為害怕不能驗收（因為驗收必須要所有住戶簽可），則努力配合每一個住戶的要求，「反正你說什麼，我就作什麼」，邊蓋邊修，邊想邊作，就算蓋好了，如果某個住戶看到現況和自己想的不一樣，也可以要求打掉重來，房子蓋好了，整體是否美觀，結構是否安全、完整，到底它能不能住人？還算是棟房子嗎？嗯，再說吧！
相對於機關需求的多變，開發廠商也常常無法掌握住機關所提出需求的「真正」意思，就算是一份經雙方簽認的紀錄，都不能代表雙方有實質的共識，可能到了開發作業的後半段，機關才會發現廠商誤解了自己的意思，而這中間的過程，對於雙方而言都是虛工，造成這種現象一方面是由於雙方領域知識背景的差異所造成的扞格，不僅習慣於用自己的經驗、認知或語言去表達單方面看法，而且有時候會以自己期望的結果去解讀對方的意思，選擇性吸收訊息，而另一方面則是因為廠商系統分析師對於機關作業的不熟悉，了解不夠深入。
在資訊管理的領域裡，從結構化到目前的UML物件導向系統分析設計，資訊專家先進們提出了不少工具來建立需求與技術人員雙方共同的語言，但實務上，不用說一般公務員，就算是行政機關的資訊人員也未必皆能了解這些工具圖表，同時廠商間由於技術、人力及規模的差異性，所採用的方法未必相同，還有一些仍停留在以程式設計師個人經驗為導向的「土師仔」公司，需求的提求，只是一句話而己，問題就更嚴重。
二、RFP研擬困難、預算難以客觀估算，採購作業耗時耗力
機關在系統招標，對於RFP(建議書徵求說明書，Request For Proposal)內容研擬的困難所在，主要在需求定義的寬鬆掌握不易，定義得嚴謹，後續功能的調整受到限制，並且增加RFP研擬工作的困難，定義得寬鬆、模糊，雙方都可能有過大的解讀空間，廠商又經常會有錯誤的理解，難以估算合理的標價，甚至引發雙方履約爭議。
資訊系統開發的預算如何合理估算，則又是另一個困擾著政府機關的IT部門的問題，目前最常被引用的方法就是依據政府採購法相關子法「機關委託資訊服務廠商評選及計費辦法」及中華民國資訊軟體協會所訂定的「資訊軟體計費要點」，但是這兩個方法，又有太多自由心證的考量變數，例如系統每個階段所需的人月就難有客觀的標準，甚至大多數的時候，都是根據既有的預算去調整、套用這些公式。
系統的實際發包作業，由於內部溝通、政府採購法要求及諸多行政作業流程的限制等因素，從規劃到實際完成委外決標少則兩個月，多則一年以上也並不稀奇，這段時間，對於一些既訂計畫，或許是差強人意，但對於主管或單位突發的急要或階段性需求，就顯得緩不濟急了，有些時候不得己只好”ㄠ”廠商，但是”ㄠ”不到，或是?有廠商可以”ㄠ”時又怎麼辦呢，就像船都己經跑了，票還不一定買到，遇到這種狀況，主管或單位又如何看待資訊部門呢？！
三、一人一把號，各吹各的調
直覺上似乎同一類行政機關對於同一種行政作業都應該相同才對，但是事實上卻未必如此，各機關會因為承辦人或主管的習慣、喜好或對於法令理解的不同，對於同一個行政流程會有不同的作業及表單格式要求，以筆者曾經進行過的臺北縣各鄉鎮市公所某系統為例，原本以為該作業一貫係由中央到地方一條鞭管理，各鄉鎮市公所作業理應一致，開發一套系統就可以通行無阻，但是實際進行後才知道，每個鄉鎮市公所都有其特殊考量，覺得不合理，要求訂定全縣相關作業的標準流業程序，但幾經折衝後仍是「尊重」各基層的意見，成效因此大打折扣。
不僅機關間流程可能不同，就算相同流程，不同機關，甚至同一機關不同單位間對於同一作業流程電腦系統都可能重複發展或購置，以台北縣財產管理作業為例，過去各機關、單位、學校都會各自購置自己的財產管理系統，就個別機關來看經費都不多，但是合計起來數字就非常可觀，筆者曾經粗估，如果臺北縣各所屬機關、單位、學校都要建置一套完整的財產管理系統（包含動產、不動產、消耗品、非消耗品等），不含主機費用，總計至少約需1億2千萬元，而且就算花費這筆費用了，因為資料庫散在各處，縣府仍然不能即時彙計目前全縣的財產狀況，後來我們建立一套整合的財產管理系統來統合全縣各單位所有的財產狀況，總計則花費不到一千萬元，類似這種狀況，不只財產管理一項而己。
仍以蓋房子為例：每個機關都在蓋房子，但礙於各機關各自經費不多，人員不夠，每個房子都蓋得不高，但每棟大樓的主人，為了彰顯自己的成果，都會把外表妝點得美輪美奐，頗具特色，就階段而言，成績是亮麗的，只是由於各別房子地基都不深，都?有辦法再蓋高，結構也不夠穩固，每四、五年房子不夠用了，大家就把房子敲掉，重頭開始，但試想如果大家能集結力量，結果可許就不是如此。
四、廠商及人員的異動
新的廠商，新的成員在進入一個機關、單位時都有一段磨合期熟悉彼此，由於每一個系統都可能導入一個新的開發廠商，雙方成員也經常在專案執行的過程中發生異動，這種情形對於專案的連貫性，會產生是負面的影響，北縣府資訊單位承辦系統開發的同仁，有很多時間不用在系統本身上，而是花費在與不同廠商、不同專案經理的週旋，而對於廠商而言，面對業主不同承辦人間的差異性，相信一定更覺得難以因應吧！
五、推動及驗收不易
一個新系統難免會影響某些人的作業習慣，甚至牽涉到既有流程的改變，而這種影響或改變對於一些公務員而言往往不想、不願或害怕去接受它，以致造成系統在推動的過程中經常會遭遇到積極的反抗或消極的不合作，最嚴重的狀況，就是導致系統開發完成後卻根本?有使用。
到了驗收階段，目前各單位的作法大多要求必須使用單位簽認（確認符合需求，並且分擔責任），但其中卻可能產生一夫當關，萬夫莫敵的問題，一個承辦人或部門主管對於系統的不滿意，就可以阻礙全案的進行，不去談可能的道德風險，就純以系統功能面的要求來看，也未必合理，在北縣的經驗裡經常發生同仁自己的個人電腦有問題卻非要歸責廠商的現象，時程的延誤不僅影響廠商，對於機關本身也不利，有時候甚至會迫於預算執行率的壓力，退縮對於品質的要求。
六、系統無法整合
於機關內不同行政作業間往往彼此相關，很難作獨立的切割，但是現在的採購方式往往都是按單位或特定業務作標案切割，其結果很容易造成各機關內之流程、資料無法整合，我們常常在系統開發中發現，需求文件中模稜兩可、輕描淡寫的一句話，卻會盤根錯節拉出一大串，缺少其中一個環節，即無法連貫整個作業流程，以北縣府前兩年開發的資產管理系統為例，原本的構想是建置一套從請購到財產登錄的自動化系統，最後竟能牽涉出必須同時開發工程管理系統的需要，同時各單位進行管理資訊系統開發時，亦由廠商自行根據其系統需要，直接定義資料庫的Schema，資訊部門很難能夠真正掌握資料庫的內容，更難達到所謂的資料的整合（data integration）及資料的共用（data sharing）的目標。
七、系統開發方法論、文件及作業環境不一致
各機關針對個別系統進行招標時，為了避免?標及公平性的執疑，多不會在開發方法論或作業環境有所限制，對於應交付文件亦多只是作概念的標示，而欠缺實質內容及格式的要求，於是各家廠商會根據自己的需要，各自引進其專長的系統開發工具、資料庫及應用伺服器，而且文件品質良莠不一，其結果不僅增加了機關後續維護、設備及版權成本，更對於系統的整合構成了不利的影響。
八、對於原開發廠商的依賴性
過去在封閉系統時代，從硬體到軟體由於均受限於單一廠商，常常遭到不少執疑，但是持平而論這類系統由於技術門檻較高，廠商一般而言較具規模，維護及服務亦能維持一定的水準，但時至今日，硬體設備、作業系統及資料庫固然都號稱是開放性架構，但是各單位自行開發的管理資訊系統卻依然是封閉的，而且問題更嚴重，技術的關鍵仍是由原開發廠商或開發工程師所掌握，不僅其他廠商難以維護或作後續功能的擴增，就是同一家廠商的不同工程師，也可能無法維護另一位工程師所開發的系統，因此原開發廠商的興衰、經營走向，甚至內部工程師的到離職都可能影響系統的運作，而且廠商交付的原始碼及文件是否真的和現況一致，內容是否齊全亦不無疑問，更加深了機關對於原開發廠商的依賴性。
九、忙！忙！忙！永無休止的系統開發工作
以臺北縣政府為例，府本部大約有二十個一級單位，縱使一年可以完成四個一級單位管理系統的開發，大約也至少需要五年的時間才有可能完成府本部全部資訊系統的發展，這個時間約就等於系統的生命週期，也就是說一切理想狀況下，剛完成全部的資訊系統發展，大概就必須開始更新第一年所開發的系統，由於廠商所提系統文件普遍不夠周全、完整，再上五年來雙方人事的更迭及技術更新，大多數單位的作法都是重新開發，至多只是作到資料移轉而已，就這樣以五年一個週期重複的在作開發、上線、報廢、再開發的工作，況且對北縣府資訊部門而言我們所負責的單位不只二十個（北縣府所屬機關、學校總計超過400所），軟體生產力也很難達到一年即可完成四個一級單位的目標，其結果就是系統開發永遠?有完成一天。
十、資訊安全的隱憂
很多資訊部門對於一些主機、網路及機房等核心管理業務不敢委外辦理，其原因最重要在於資訊安全的考量，但是很矛盾的對於更核心的資訊系統開發，資訊部門卻往往?有能力控制，曾經從事過程式設計師工作的讀者，可能都有一個經驗，為了測試及維護方便，會在其開發的程式中放入一些後門或是設定一些特權帳號，但過了不久連自己可能都忘記曾經放了什麼，這尚且是?有惡意、無害的情形，但是只要遇上一個有心人，後果可能就不堪設想，多少防火牆或入侵偵測系統，大概都很難避免禍起蕭牆，北縣府在多年前就曾發生，有某公司的工程師，因為要追求縣府某位女同事，透過其開發的系統調閱其個人資料，並且幫她修改差勤紀錄的事件，後來是因為差勤紀錄被修改的痕跡太過明顯才東窗事發，但這是否係唯一的一個案例，黑數有多少，筆者真的無法保證，當然，各機關大多會要求開發廠商交付保密安全協定，系統文件、程式碼，但這些文件提供給機關的是安全的保證，還是空虛的安慰。
面對這些系統開發工作所遭遇的問題，縣政府將如何突破？將於下期的《資安人》繼續介紹。