政府機關資訊系統的發展和使用過程，發生的一些問題常常都是重複性的共通問題，這些問題包括政府機關需求的多變，以致於經常造成廠商理解的差距，敢怒不敢言；採購作業耗時耗力；中央到地方各單位考量需求不同，各吹各的調，行政流程一條鞭的困難；廠商及人員異動；推動及驗收不易；系統無法整合、文件作業環境不一致；委外的資訊安全隱憂等，這些問題筆者在25期的《資安人》已詳述，以下將就這些問題來談解決方案。
系統整合
筆者最早的目標重點放在建置包含縣政資料庫、AP Server、流程引擎、報表伺服器、目錄服務系統等整合的系統環境，並在招標文件中要求廠商在系統開發時都必須根據上述環境發展，這種作法固然改善了部分系統環境整合的問題，也減少了各自建置伺服環境的成本，但是主要的問題仍未獲得改善，同時又產生了一些新的問題：
一、要求廠商配合機關既有系統環境進行系統開發，意謂著廠商無法使用過去習慣的工具，同時以前開發的類似程式也不能夠在縣府重複使用，使得廠商必須耗費許多時間在工具的重新熟悉與了解上，不僅可能降低軟體的品質（他們也是初學者），也墊高了廠商的技術與學習門檻，而且廠商在北縣府為熟悉新工具、新方法、新環境所投入的心力及開發成本，往往只適用於北縣府，無法引用至其他機關，其成本未必划算，間接影響廠商參與北縣府標案的意願。
二、任何系統環境都有其技術門檻，雖然我們在建置作業環境時努力作到開放，但是由於北縣府本身的資訊規模、架構就十分龐大、複雜，一般廠商要想切入確有一定難度，有些環境建置商就會藉以向開發廠商收取額外的「整合」或「顧問」費用，增加了額外的成本及問題。
三、一些廠商會因為在共同作業環境開發程式成本及難度較高，就設法包上一層MiddleWare，一方面降低成本，方便其日後的維護，一方面也滿足縣府招標文件的要求，但是這麼作法不僅降低了作業環境的運作效率，而且未來也很難進行環境軟體維護及版本的更新，更可能影響其他的系統，筆者以下面這個例子比喻：我原本買一台跑車代步，因為我不會開車所以找了一個司機，但是這個司機也不會開，於是他買了兩匹馬，掛在跑車前面，拉著跑車走，我問他怎麼回事，他很驕傲的告訴我：他充分滿足了我的環境需要－使用你的車，功能需求－車會跑，而且還「自由回饋」兩匹駿馬。
核心系統自行開發
這種情況持續了若干年，筆者明知存在什麼問題，卻一直苦於找不到一條有效解決的方式，一年多前行政院研考會推動共通平台建置案，給了筆者第一層的答案－「重新打造一套完整，又可以同時為自己及大多數廠商熟悉的應用系統作業平台」，但這個答案完整了嗎？好像並?有，因為這只是改善系統執行環境的技術問題而己，真正重要的問題還?有解決，但是另一半的解答在那裡呢？直到去年四、五月間，筆者偶爾觀賞到Discovery頻道介紹美國波音公司如何製造飛機後，筆者得到了答案：飛機所需要的所有零組件，波音公司本身不生產，係交由全世界數十萬個合作零件生產商製作，再透過其嚴密的控管程序統一在西雅圖組裝，這種方式波音公司不必花費高昂的人力成本去生產零件，並保有其核心技術及商業機密，零件生產商也不用會製造整架飛機，只需專注於他的專業即可，而在雙方的界面方面，由於零件組成簡單，規格及品質的要求皆能定義明確，不容也不會有任何模糊的空間，而且就算某個零件商發生問題，也可迅速找到替代廠商，但是目前北縣府開發資訊系統的情況就好似自己?有設計圖、工具及技術，卻單純只想委託其他廠商設計及製造整架飛機一般，再想辦法去驗收，是不可能掌握得住技術的核心，驗收不易，受限於原開發廠商及其他問題的產生，也就在情理之中了，筆者至此很清楚的確知要想解決目前的問題，不僅要建置一個應用系統共同的作業平台，更需要跳脫現有應用系統的招標及開發方式，建立起自己的核心系統開發團隊。
完成整體解決方案
在經過李智博士悉心指導，規劃廠商宇太新公司不計成本的投入以及多位資訊先進前輩的指導之下，我們完成了包括「管理資訊共同作業平台」、「核心系統開發團隊」、「軟體元件委外」等三部分的系統發展整體解決方案設計，簡述如下：
管理資訊共同作業平台：
包含九大系統服務中心，其內容摘要如下，並請參閱圖一：
1.單一入口中心：建置應用程式入口網站，提供本府同仁應用系統、電子表單及報表服務之統一入口界面，使服務由系統導向轉換為以使用者為導向，以報表為例，過去要執行某項報表必須要進入該項系統去選用，但以使用者為導向的設計，則打破原有系統的界限，報表不再以單一系統角度設計，能夠按其權限將使用者可使用的報表全部整合呈現，。
2.目錄服務中心：改變現有目錄服務系統以組織階層為主的單一目錄樹結構設計，調整為「人員」、「組織」、「應用程式」三顆目錄樹，提供各項應用系統更為彈性的驗證、授權的基礎。
3.電子表單中心：建置各項電子表單統一的申請及簽核等線上流程服務。
4.報表服務中心：建置統一的報表列印及查詢服務。
5.應用程式中心：建置各應用程式資料同步及非同步異動之服務架構，提供各應用程式間資料交換服務。
6.批次作業中心：建置批次作業中心，統一管理應用系統各項批次處理作業。
7.資料處理中心：建置核心資料庫，並整合現有應用程式資料，同步異動至核心資料庫，統一管理各應用系統之資料庫。
8.稽核紀錄中心：建置各應用系統運作之稽核紀錄系統，集中提供管理者檢核及除錯資訊。
9.建構管理中心：統整建立系統發展測試環境，從系統分析、系統設計至系統維護階段，提供上線前執行
核心系統開發團隊
在經驗裡，再開放的平台只要和廠商現有開發環境不同，對於廠商而言都是額外的技術門檻，而且廠商要能開發系統，在實務上必須準備一套和業主相同的開發環境，這對於軟體業者而言，成本上幾乎是不可能的事，所以平台建置完成後，如果仍然是提供一個環境，要求廠商配合這個環境開發系統，可能只是製造出另一個更高技術及成本障礙，所以在我們的構想裡，伴隨著的「管理資訊共同作業平台」的建置，建立起縣府核心系統的開發團隊，並且在系統開發團隊建立的同時，同時完成軟體開發流程及品質管理機制的建立，才是全案是否能夠成功的關鍵。
核心系統開發團隊的目標就是縣府自己能夠實際使用「管理資訊共同作業平台」發展各項管理資訊系統，開發系統團隊的組成包含系統分析師、資料管理師、流程管理師、程式設計師、專案管理等各類成員，而其來源，除主要管理人員外，一般程式設計師及技術人員皆將採用委外人力，委外人力的所屬公司除負責派駐人員的訓練、薪資、勞健保及退休等事項外，該等人員之任免及工作內容皆依縣府指揮，而契約屆滿或因故終止或解除時，縣府亦可在尊重其本人意願的條件下，將其轉介至下一個公司，藉以保障其個人的權利，增加其向心力，也就是筆者常說的「換公司不換人」，力求兼顧用人的穩定性及彈性。
軟體元件委外
個別軟體委外的標的將由整個系統轉變為軟體元件，軟體元件完成開發後再由縣府核心系統開發團隊加以組裝，軟體的製作將不涉及任何特定的工具，而為能使軟體元件規格的訂定、交貨、品質驗證及組裝有一定的標準，目前我們也正訂定相關文件。
正面效益
我們預期整個架構體系如果能夠順利運作起來，對於縣府及軟體開發廠商會有下列正面意義：
1. 責任界面明確、簡單，對人力委外公司而言，所負責的工作就是選派訓練完整，最適當人員進入縣府服務，對軟體元件製作廠商而言，只要按照縣府的要求，製作元件即可，兩者都不必再為系統的流程或需求負責，而廠商及縣府間也不必耗廢額外的行政溝通，而都能把時間花在系統發展的工夫上。
2. 「換公司不換人」能夠創造一個較為穩定的開發團隊，其技術、經驗以及對於組織的瞭解與熟悉度，都能逐漸加以累積，使得開發的成品，更能符合縣府的需要。
3. 大幅簡化採購程序，如果本計畫能夠完全推動，整個縣政府對於系統開發大約只有兩類「人力委託」及「元件開發」，前者可能三、四年才需要進行一次，後者則由於標的簡單，相關的採購及驗收程序亦相對容易，甚至可以建立若干類似特約元件供應商的機制。
4. 整體軟體環境能夠掌控，開發流程及文件標準化，系統整合較易落實。
5. 軟體是逐步成長的，而不是每隔幾年就必須再從零開始。
6. 個別工程人員或承包公司對於系統的影響，都在有限且可以控制範圍內，不會因為個別人員的到離職，或個別公司的興衰榮辱，就影響某個系統的運作或後續發展。
7. 安全性較容易管理，對於元件供應廠商而言，透過建構管理及其他機制，不難對於其所交付的元件作安全檢驗，而委外人員部分，則回歸至人的管理，固然有相當的難度，也?有人能夠保證委外人員不會出問題，但相對於過去必須面對廠商及其內部員工雙重風險而言，還是簡單許多。
8. 後續功能的擴充、調整較具彈性，過去系統功能異動時，廠商基於其商業考量，雙方經常產生是否應付費及費用是否合理的爭議，但改變委外作法後，我們自己就是軟體開發者，對於系統功能的新增及修改具有高度的彈性。
總結
當然以上的作法和目前其他行政機關的習慣及思維有很大的出入，自然一些先進及朋友曾經給了筆者不少指教，這些問題或許也是您的疑問，筆者謹就其中要項作一些回應：
1.公司的起伏是影響系統發展及維護的變數，委外人員不也會經常產生異動嗎 ?
筆者認為：公司起伏的變數我們?有辦法控制，而其影響面較大，委外人員的到離職卻是我們比較能夠事先知悉，影響面也較小，而且職場的轉換原本就是很正常的社會學習及個人歷鍊過程，無論採用任何方法都無可避免，重點應該是設法讓委外人員對縣府產生向心力，使他喜歡這個環境，這份工作，同時在制度及技術的設計上，消除或減少任何一個人員到離職所可能產生的衝擊及影響，而這方面在北縣府平台及開發流程管理中已經考量。
2.委外人員的安全性？
筆者認為：如果你能夠信任現在系統開發廠商的員工，為什麼不能信任委外人員？委外人員可以透過事先的安全調查、業務分工與稽核制度來提昇安全性，但是對於廠商內部員工我們可能就?有辦法了，資訊安全問題並?有變得更壞，卻有可能變得更好。
3.每天或每個階段工作成果難以檢驗，特定系統也?有廠商負責，到最後可能忙了半天，卻生產不出一個系統。
確實有此可能，現有的系統委外開發方法有一個很大的優點，就是每個系統都有一個責任廠商，反正不管怎麼樣廠商就得完成履約，無法履約，無論是罰款、解約、停權在行政上都有一個追究的對象，但如果是機關自己的系統開發團隊，那就是自己的責任了，公務員一談到責任，問題就大了（平安就好，幹嘛管那麼多），尤其是大多數公務人員（包含機關內資訊人員）並?有實際從事或主持大型系統開發的經驗，在心理上產出抗拒、沒有信心、甚至在技術上確實力不從心，都是可以理解的，雖然在本平台上我們為了控制軟體開發的進度引進了各項專案管理及建構工具，但實際執行下去，是否能夠真如理想般落實，筆者也?有十足把握，但個人認為縱使不能作徹底的改變，但最基本應該可以作到改善現況。
最後筆者以一句話作為結尾：作任何新的嘗試總有一定的風險，但是方法如果不變，結果就不可能改變，問題也將永遠存在，總是需要有人願意在前端充當烈士，時代才會改變，不是嗎?!