規劃完善的委託外包案

Chapter 4

以資訊系統委託外包案之個案，進行規劃分析：

導入資訊系統為各公家機關之電子化過程中，必要之措施。資訊系統大型者，如：機關核心業務系統（關稅總局之於關貿網路系統、貿易局之於廠商貨品管理系統）；而資訊系統小型者，屬一般公務人員經常接觸的系統，如：差勤系統，公文系統，內部網路知識管理系統，等等。

一般而言，公家機關導入資訊系統之過程，不外乎：

１．機關內部使用者提出需求

２．資訊單位研討作業資訊電子化的可能性

３．機關高層會議通過導入資訊系統

４．資訊單位進行招標流程

甲、蒐集資料及研討需求

                                                 i.                確認需求是由資訊單位人員主導，召集需求單位熟悉業務的人員，針對組織業務功能、作業流程做一全盤瞭解，可能要重新定義業務流程、重新分配資訊資源。而硬體架構、開發環境及平台需求確認，由資訊單位人員主導，考量現有資訊設備、作業環境及未來組織資訊應用的方向，再根據外在資訊科技的可能的變動等因素來定義需求。必要時可以委託外界資訊廠商、顧問來做。需求確認後用文件詳細描述，並要求廠商於建議書中，詳細說明所使用的整體系統架構、開發方法、技術與工具。

乙、撰寫建議書徵求說明書（Request For Proposal, RFP）

丙、邀請相關單位提供意見：建議邀請政風、採購、會計、法規及資訊等單位召開會議徵求意見並作成會議記錄。

丁、修改建議書徵求說明書：依照會議記錄修改建議書徵求說明書。

戊、簽會相關單位：建議書徵求說明書完成後依程序簽會政風、採購、會計、法規及資訊等單位。

己、核定：由權責單位核定。

庚、移交採購單位：奉核定後移交採購單位辦理招標事宜。

辛、製作招標文件：採購單位收到業務單位移送之建議書徵求說明書後，即製作招標文件。

壬、遴選評審委員

癸、委外廠商之遴選：廠商提出計畫書（proposal）、並至評審會議進行簡報，考慮廠商的能力、經驗、對機密資料保密的能力，以最適切遴選準則來選取委外廠商。

                                                 i.                廠商資格規定，包含廠商的特性，如廠商的背景、廠商的資本、廠商的營業狀況、廠商的資源、廠商的長期穩定性、廠商委外的經驗、廠商服務的品質符合ISO 9000 及廠商的規模。資訊委外作業一般採用招標的方式，必須規定廠商的資格，以確保委外業務品質。

11、公告評審通過前幾名廠商

                                                 i.                依據系統的特性，訂定廠商遴選的審查項目，不同系統的特性有不同的審查項目。委外的廠商如對遴選的審查項目有意見，廠商可以在建議書提供意見。另外，訂定規格文件評分比重，說明審查項目的評分基準及說明總分計算方式。說明遴選的評審規則，如採用資格標、規格標及價格標。資格標是說明廠商必需符合與具備「投標廠商資格」的所有條件。廠商資格標不合格，其規格文件不予審查評分。規格標評分規格文件，其總分達到某一分數者為入圍，入圍者始可參加價格標。

                                               ii.                廠商之遴選分為三個階段進行。(1)資格審查：廠商必須符合與具備「投標廠商資格」的所有條件。若資格審查不合格，廠商建議書之規格文件不予審查評分。(2)規格審查：評分廠商建議書之規格文件，其總分達到某一分數者為入圍廠商，入圍廠商始可參加價格標。(3)價格標：入圍廠商進行所報總價比價。

                                             iii.                另外廠商的技術能力，可由建議書中所提供的實績單位，以訪談方式瞭解廠商的術能力、信譽、服務品質、不良記錄(如違約)及系統無法驗收記錄等等。

12、依名次與各廠商議價（最接近底價者得標）

13、招標流程：

                                                i.                公開招標：邀請不特定廠商進行評審

                                              ii.                最有利標：入選合格廠商，並排名

                                            iii.                最低標：入選廠商，參予競標，議價接近底標者勝，依名次與個別廠商會晤，每個廠商有三次提標機會。

５．與廠商訂定合約：合約規定宜採用分段交付、分段測試確認的方式。對於變更的程序，嚴格控制。明定交付系統及文件的程序，明定逾期確認的責任。

甲、合約是規範業主與廠商之間的權利義務，合約的內容包括標的物、服務期限、服務費用、付款方式、專案人員、標的物點交、安裝、確認驗收、相關的罰則及合約的修訂及中止。為避免合約的爭議，宜採用下列措施：

                                                  i.                分階段發展，分階段確認：軟體工程的理念即在分階段發展，分階段確認，以期提早發現錯誤。軟體發展另一特性是其規格無法在一開始即可明確的詳列，而是經由每一階段的發展，使規格隨發展之進度而愈來愈明確，換言之，軟體規格係經由發展而確定，而非一開始即加以明確訂定。因此，若能貫徹軟體工程的理念，分階段發展與分階段確認，自然可以消除規格不明確的爭議。

                                               ii.                明定逾期確認的責任：若造成專案進度落，當交付文件遲延發生後，業主欲以逾期罰款處理，廠商則反而以確認時間太長造成交付逾期，向業主要求損害賠償。因此，雙方應於合約中約定確認時間，業主得以此要求使用單位如期完成確認，如逾約定之確認時間，則視同確認。又使用單位未在期限內提修正意見，即同意廠商所做之各項規劃設計，如此，使用單位為掌握修正的機會，必會認真如期的完成確認，使進度能掌握在可控制之範圍內，而經確認之文件即是明確的規格，規格爭議自然消弭於無形。

                                             iii.                約定確認後之文件為合約之一部分：每一階段經過確認的文件，即是規格的一部分，當完成所有文件的確認，其軟體規格亦隨之確定。因此，確認文件對雙方應是具有法律上之拘束力，始能維護雙方之權利。廠商應依確認後之文件發展軟體，而業主則僅能依確認後之文件作為驗收依據。

                                             iv.                約定法令修改時配合修改規格的分界點：在許多的委外服務案例中，經發包之後因政府法令修正，或政策變更，而其變更內容又與軟體功能有極密切的關係，若未按新法令或新政策作修正，其軟體功能顯然是無法滿足使用者的需求，因此修正軟體規格是勢所必然，只是分界點在何處，始為合理適當。若系統已接近驗收階段，法令才修正，此時軟體規格再作重大調整，而由廠商承擔成本及時程增加的責任，顯然是不公平的，因此應訂定一個合理的分界點，通常可約定在細部設計確認前，在此之前廠商應調整規格，之後，廠商可不作調整，或可修訂合約價款與交付時間因應。

６．合約的執行與管理成立專案小組，指派負責人員，隨時監督追蹤專案的進度，並排除可能造成延誤的因素。指派人員負責審查、確認與驗收廠商交付的項目。指派使用者接受廠商所提供的訓練。

甲、專案管理：專案管理活動的開始首先選擇負責專案的專案經理、接著決定專案小組的成員、工作定義、估計預計完成的時間、成本估計及專案發展的控制。成功的專案發展，需要小組成員全心全力的投入，在規劃完善的計畫下配合人力、財務等資源的適當援助才能成功。委外的資訊作業，在合約規定期限內，廠商對業主業務需求、系統功能、細步工作流程內容，做詳細的溝通及瞭解，並依合約規定方式採分段陸續交付各項文件、子系統；業主需對交付的各項文件、子系統進行審查、確認是否符合需求。雙方組成專案小組定期召開工作會報，以掌握工作進度、品質保證、並監控時程。專案管理另一活動為專案的監督，一般以月工作報告、協調會議、查核開發過程文件、覆查及審查等方式來掌握專案執行的績效、進度與經費使用情形。專案組織人員，通常有專案經理、專案協調人員、系統分析師、程式設計師及工程師等組成。茲將資訊系統委外的專案管理之關係歸納如資訊系統委外的專案管理圖：

乙、需求變更與建構管理：變更分為系統發展階段的變更和系統維護階段的變更。在系統發展期間，因環境或作業需求改變，或基於技術層面考慮而導致系統功能變更，均應有一明確之作業程序，以使系統功能變更作業有所遵循，以保證系統功能仍有一致的規範，並可在預期的時程內完成。廠商應填具變更表，說明功能變更程序及相關處理單位權責，此程序應包含變更提出、變更評估及變更確認等步驟，經認可後據以執行，其表格內容至少包含：

                            i.                變更原因：說明為何需做變更。

                          ii.                變更說明：完整的說明需求變更的事件，對系統、使用者造成的影響及開發時程的衝擊。

                        iii.                變更之處理程序。

                        iv.                變更之文件或作業流程名稱。

                                               v.                變更前後之系統文件。系統維護階段軟體之更新及硬體設備的更動，均會對系統維護作業造成影響。廠商須提供一套完善的管理方法、作業制度及使用工具（如軟體版本的控制），以使各項變更作業均能有效的控管不致影響正常作業。廠商應於建議書中說明針對各種變更作業，所提供之管理方法、作業制度及輔助工具。為確保產品版本正確性，得標廠商應使用工具建立並執行建構管理制度，對建構項目進行控管工作。列管之建構項目應至少包括應用系統軟體程式碼、軟體發展文件、測試計畫及各項工作計畫、各項交付文件等。得標廠商應於決標日起一個月內提出建構管理計畫，經認可後據以實施。

丙、品質保證措施：廠商在系統發展過程中應具有品質管理的作業，以確保工作的正確性及產品的品質。說明在不同階段之品管的作業，包括作業程序及標準規範、品質保證標準與技術，品質保證時程與重要查核點、品質保證作業資源與人力規劃、可能風險評估與預防等相關項目，並應規劃各項檢驗與測試工作。

丁、風險管理：

                            i.                廠商須於建議書中提出對於本案之風險管理方案。

                          ii.                廠商若未能履行本標案相關規定，其連帶保證人之應變計畫。

                                             iii.                專案進行期間，為達成稅務資料安全保密之目的，其安全管理之措施。也要在合約條交款詳細規定。

７．資訊單位與廠商連絡，規劃各標的物件交付時間（即專案管理中，里程碑時段中所應交付的物件，如：系統設計書，系統規劃書，雛型程式碼等）。

８．資訊單位協調廠商與機關內部使用單位接洽，進行需求徵詢，與設計系統之方向

甲、需求徵詢會議次數，得視廠商製作系統所需知識充足與否、使用單位所提出之需求與現行作業是否相符、資訊化後作業流程是某有不周之處等等，進行溝通協調，使未來完成資訊系統，不會有冗餘之功能，得到真正符合需求之功能

乙、廠商在製作系統時，難免會遇到，對使用者單位專業知識的不慎了解，因此頻繁地與使用者溝通，為不二法門。

丙、使用者對其業務比資訊人員有更多的了解，資訊人員必須充分了解使用者的知識，避免存有片段的知識，造成片段的功能。使用者需有義務提供整個業務的概況，各作業流程的詳實資訊，有時使用者不能在一時間就把他的業務流程，全盤託出，這點困難，解決方向有：

                                                 i.                使用者自己做功課，將他的需求與作業流程寫成書面報告，避免口頭報告的內容遺漏。

                                               ii.                廠商必做出簡單功能的使用者介面雛形系統，與使用者溝通，以釐清使用者不需要的功能，與真正必要的功能。雛型系統是不斷改進的系統，使用者可從過程中，針對其操作的功能，了解其作業流程的流暢性、簡單性、以及是否合乎公家機關之公文簽審作業習慣。

                                            iii.                唯現況下，承攬廠商只使用傳統之系統發展生命週期 (System Development Life Cycle；SDLC)，其缺點是不容易達到使用者所需之功能。

                                            iv.                資訊人員是搭起廠商與使用者之間的橋樑，資訊人員必須在系統開發階度，努力的了解使用者的業務需求、作業流程、相關背景知識等，並且要了解廠商這邊的系統設計架構、資料庫設計、程式開發環境、程式中SQL語法所涉及之資料檔案存取方法等。以利資訊人員在系統開發完成後，所面對的系統維護工作。

９．測試工作

甲、資訊系統設計完成，進行系統測試的工作，公家機關通常進行平行測試，舊系統還是正常進行運作，此時，新系統餵與舊資料與新資料，測試是否仍有bug，幾個月後，再由新系統接手舊系統的業務。

乙、若此資訊系統是新系統，無舊系統與其負責相同業務，則進行上線測試。

１０．        教育訓練，乃由廠商提供課程，供使用者操作之教育訓練，供資訊人員維護之教育訓練（通常是架置系統流程，備份維護）

１１．        運作與維護：確立系統保固的流程、執行系統的維護，評估廠商的表現，做為繼續與該承包商合作的依據。

甲、明確訂定系統運作前與系統運作後的服務水準。系統運作前的服務水準如網路服務水準、應用系統服務水準、支援服務水準及教育訓練服務水準。系統運作後的服務水準如維護內容及於維護服務水準(包含作業績效、作業回復及系統效率)。

乙、運作與維護是指廠商對於委外作業的支援與作業的維護。支援的事項包括資料庫系統、網路管理、硬體設施(含個人電腦、網路設施、印表機)及應用系統提供技術支援與維護。廠商派駐人員支援，駐點人員遵循駐點人員管理辨法。

１２．        後續維護工作

甲、廠商通常有一年的保固維修，派駐人於至資訊單位（通常派小程式員，只會修簡單網頁，若資料楚力錯誤，就只能修改資料庫），雖沒有什麼成效，但聊勝於無。

乙、使用者使用資訊系統，若發生錯誤，要請求資訊單位，進行系統修改工作，得填寫「需求申請單」交由資訊單位處理，而使用者可自行與廠商駐點人員接洽，進行資料庫內資料維護工作。

丙、因為使用者單位業務繁忙，時常不能審視資訊系統的可用性、適用性，而不能正視資訊中心所提出的疑義（例如舊系統資料庫所存在的錯誤資料如何發生）；或者，廠商駐點人員，規避複雜的程式修改（駐點人員不清楚系統架構，必須轉交資訊人員從頭訓練），而僅在資料輸出端即資料庫中，去修改錯誤資料。

１３．        保固期過後，與廠商所進行簽約，展延保固維護期。通常此時會提出某子系統流程的大幅修正，廠商針對需求必須重新設計某子系統，而使得政府機關預算超支，比如政府規定維護費需為原系統製作費的10％以下，但往往維護費為15~30%之間，端此可見資訊系統委託外包案，若沒有完善的規劃，其結果可能就是，系統功能不合需求，設計不良，導致系統必須從新設計，超支經費，浪費公帤。

問題剖析：

１．                委託外包案，其得標之資訊公司，必須嚴審其公司財務狀況、經營狀況，不然若遇到公司倒閉，則資訊系統乏人維修，且當其公司人力流動頻繁，將使政府機關之駐點人員，替換頻繁，其駐點人員的訓練，竟委由政府機關之資訊人員代訓，不僅徒增代訓所浪費的時間，更使政府蒙受信譽的損失。

２．                資訊系統專案，經常面臨潰敗的危機，合作廠商若以最低標得標，導致期錯估開發所需經費，導致製作期程延宕，使政府機關與廠商的互不信任，使專案失敗。

３．                日前推出Studio .Net 2005，此套工具實現了Virtual Team的功能，藉由專案經理分派工作與系統分析師，系統分析師將系統模組化，並將各模組程式設計工作派與程式設計師，程式設計師可於函式資料庫中，尋找類似功能的程式片段，加以修改成合適的程式片段。

相關議題

１．                近年來由於政府財政緊縮，政府機關為節省資訊開發成本、促進資訊資源整合共用及輔助資訊業者，積極推動政府資訊作業整體委外，惟整體委外不限於資訊軟體應用系統，還包括硬體、網路設備及人員轉換等。而資訊業者認為以價格導向競價模式會帶來弊病，由一家廠商在本身無法獨立完成下，會採行下包模式，導致整體系統品質低落的狀況。

２．                資訊業務委外所延伸的問題：使用者管理、專案管理、變更管理、建構管理、驗證管理、合約管理及廠商支援管理。

註解：

１．                系統發展生命週期：主要分成需求、分析、設計、實作、測試（包括整合測試及系統測試）等階段，階段間都是線性前進的，也就是在系統全部的需求分析完後再進行設計，全部的功能設計好後再進行實作，各子系統實作完再進行測試。此種開發過程的缺點在於開發較大型的系統時，失敗風險較高。因為它在分析及設計階段是進行整個系統的分析設計，當對象是大型系統時，便得花掉非常多的時間進行分析與設計，而且許多分析上或設計上的問題，往往要到了整合測試階段、系統測試階段，甚至是交給客戶手上時才會發現。而發生問題後，則必須再重覆整個開發過程以進行修改，此時修改的困難度與成本都會比第一次開發時還要高。

２．                雛型模式(Prototyping Model)：傳統設計方法中使用者須知道他們真正的需求並能明確界定，但事實上往往無法有效說出需求，等到系統設計好後才發現需求、資訊不對，為了讓使用者能界定他們的資訊、需求，故產生了雛型法。（速度快，以4GL為後盾，工作小組人數不宜多，且易產生錯誤）開發者與使用者先討論系統的基本需求，並由其中較具關鍵性的功能訊速開發一個可操作的系統雛型，再經由反覆的演練過程中，逐漸轉化修改成系統產品。過程：分析、快速設計、雛型操作、雛型評估與需求細化、產品化。（專家建議雛型只應視為需求分析階段之輔助，而不應將其轉為最終產品！）

３．                建議書徵求說明書（Request For Proposal, RFP）：

甲、應用軟體的需求確定之後，即可開始作建議書徵求說明書（Request For Proposal，RFP）的撰寫。此階段涉及非常多的資訊方面的知識，也有很多地方必需與資訊單位的業務作緊密的配合。故業務單位若有需要可邀請資訊單位、專家學者、資訊軟體協會....等提供專業技術協助。有些機關基於各方面的考量，也可能請資訊單位全權代理建議書徵求說明書撰寫的工作。

乙、建議書徵求說明書的製作也可以考慮與需求規劃工作合併以顧問諮詢方式委外，惟顧問諮詢承包業者不宜參加後續的專案承包。

丙、應用軟體的外包涉及很多資訊方面專業要求，相關條款應在建議書徵求說明書內清楚說明。

丁、計畫如包含資訊相關硬體設備之購置，建議應將所須費用與委外服務之經費分開編列；在遴選廠商時，亦應考慮採購手續之差異，宜分別遴選。

戊、評審合格之廠商建議書，或經技術驗證測試合格之廠商，可視需要酌付費用，並於RFP中說明。

金　額 建議書徵求說明書（RFP）參考目錄
內　容	10至100萬以下	100至1000萬	1000萬以上
1. 概述	ˇ	ˇ	ˇ
2. 專案性質描述	ˇ	ˇ	ˇ
2.1專案名稱	ˇ	ˇ	ˇ
2.2專案目標	ˇ	ˇ	ˇ
2.3專案範圍	ˇ	ˇ	ˇ
2.4專案時程	ˇ	ˇ	ˇ
2.5專案費用	ˇ	ˇ	ˇ
2.5.1計價方式	ˇ	ˇ	ˇ
2.5.2付款方式	ˇ	ˇ	ˇ
2.5.3需求變更	ˇ	ˇ	ˇ
3. 需求說明	ˇ	ˇ	ˇ
3.1整體需求說明		ˇ	ˇ
3.1.1功能需求	ˇ	ˇ	ˇ
3.1.2系統作業流程說明			ˇ
3.2技術需求	ˇ	ˇ	ˇ
3.2.1現有系統架構與環境說明	ˇ	ˇ	ˇ
3.2.2未來發展規劃			ˇ
3.2.3解決方案之需求	ˇ	ˇ	ˇ
3.2.4品質水準與測試之需求	ˇ	ˇ	ˇ
3.2.2安全控管之需求		ˇ	ˇ
3.3環境需求	ˇ	ˇ	ˇ
3.3.1硬體/軟體之作業環境	ˇ	ˇ	ˇ
3.3.2硬體/軟體之測試環境	ˇ	ˇ	ˇ
3.3.3網路作業環境	ˇ	ˇ	ˇ
3.3.4網路作業環境之測試	ˇ	ˇ	ˇ
3.3.5非交付硬體/軟體			ˇ
3.4管理需求	ˇ	ˇ	ˇ
3.4.1管理需求摘要		ˇ	ˇ
3.4.2專案組織與人員能力需求		ˇ	ˇ
3.4.3專案管理需求	ˇ	ˇ	ˇ
3.4.4需求異動之管理	ˇ	ˇ	ˇ
3.4.5廠商實績之需求	ˇ	ˇ	ˇ
3.4.6保固與軟體維護需求	ˇ	ˇ	ˇ
3.4.7教育訓練需求	ˇ	ˇ	ˇ
3.5交付產品與交付時程	ˇ	ˇ	ˇ
3.5.1第一階段		ˇ	ˇ
3.5.2第二階段		ˇ	ˇ
3.5.X第…階段			ˇ
4. 智慧財產權之歸屬	ˇ	ˇ	ˇ
5. 驗收事項與權責	ˇ	ˇ	ˇ
6. 建議書製作規定		ˇ	ˇ
6.1裝訂及交付		ˇ	ˇ
6.2建議書內容		ˇ	ˇ
6.3其它要求(若無則免)			ˇ
7. 建議書評審與廠商遴選		ˇ	ˇ
7.1評選步驟		ˇ	ˇ
7.2建議書澄清		ˇ	ˇ
7.3評選方式		ˇ	ˇ
8. 參考文件		ˇ	ˇ

４．                計畫書（proposal）: 投標廠商所提具之建議書內容請依據本專案需求及下列大綱為撰寫依據，並配合「評選項目」於建議書目錄後，整理出評分項目與建議書對照表，以方便審查及評選。

                i.       專案概述

               ii.       公司簡介

             iii.       技術建議說明

               iv.       管理建議說明

                v.       成本分析

評選項目表

評 選項 目	考   慮   因   數	權重
一、廠商背景及能力	1.廠商規模、商譽與財務能力 2.過去經驗實績與成功案例 3.與本專案類同之相關建置經驗	10
二、系統開發及建置能力	1.整體系統架構與功能 2.系統建置技術（蒐尋、分類、探索、共享、回饋、資料安全） 3.資料蒐集自動化程度 4.系統使用容易度 5.與本府現有系統之整合	40
三、專案管理能力	1.專案組織與工作團隊學經歷 2.專案實施方式與管理方法 3.專案品質管理方法 4.需求變更管理與風險管理	10
四、驗收、保固及維護能力	1.測試驗收計畫及內容 2.系統保固期間之維護方式、內容 3.教育訓練	10
五、價格	1.單價分析合理性 2.後續保固維護費用	10
六、加值、創新	1. 對本專案需求中，所提之附加效益與各項建議 2. 其他加值、創新事項或承諾	20

評選表（權重僅提供個別委員排定廠商序位之參考依據）

項次	評選項目	權重	廠商一	廠商二	廠商三	廠商四	廠商五	廠商六
（1）	廠商規模及專案組織能力	10
（2）	系統開發及建置能力	40
（3）	專案管理能力	10
（4）	驗收、保固及維護能力	10
（5）	價格	10
（6）	加值、創新	20
投標廠商權重總和
			廠商一	廠商二	廠商三	廠商四	廠商五	廠商六
投標廠商序位
備註： 評審委員簽名：

Chapter 5

一、 制度面的問題

在官僚體制中，依法行政與層級節制的決策流程是必備要素，在過程中行政人員之意見與影響力得以發揮作用，此外決策過程之合法化又牽涉到民意機關之參與互動，而影響到簽約外包之決策結果。故此處欲探討如下問題：

﹙一﹚ 組織過程，即簽約外包在行政機關辦理之過程，在此過程中參與者為何？各參與者其所關注重點為何？是否依理性之原則決策或有其他原因？

﹙二﹚ 法令基礎，包括各委外措施之法令依據為何？相關法令可能形成之影響如何？

﹙三﹚ 利益政治，即各外包案中行政單位、受託單位、民意機關間之互動如何？是否存在利益交換之現象？

二、 管理面的問題

對簽約外包過程--規劃評估、評選簽約、執行監督三個階段的管理，將影響到委外服務執行的成功與否，此處牽涉到政府與受託者之契約關係以及市場運作之機能與價值，故須以市場化的管理觀點進行分析。本研究參考Walsh(1995)所提出的市場基礎式管理之五項議題：「資訊」(information)、「誘因」(incentives)、「信任」(trust)、「品質」(quality)、「風險」(risk)，而以之檢視嘉義市政府在市政外包過程中所採取之管理策略是否符合良好合約管理之原則。

三、績效面的問題

簽約外包是否能解決施政過程的問題，滿足政府機關的需求，將決定其功能與定位，透過執行績效之探討，除了暸解政府業務委外之需求與滿足程度，亦可檢視政府委外制度與管理策略所產生之影響。此處之管理績效擬從幾個方面加以評估，即市政委託民營是否滿足當初外包之需要？以及執行過程中發生哪些問題？情形如何？由外包過程發生之問題又進一步探討行政機關是否進行有效之理？可改進處為何？

結論與建議

１．完整的簽約外包管理範圍應從決策前的問題界定、分析及可行性評估接著徵求計畫書、協商簽訂契約、一直到執行監督以及最後的成效評估，如此方可對於簽約外包之過程清楚掌控並確保服務品質，若未經審慎評估，確定外包需要，憑藉錯誤觀念或另有目的而外包，將可能影響到簽約外包或整體服務之效果，而失去解決問題的意義。

２．與學術機構合作，建立委外政策諮詢機制：由於政府受到能力、智力及時間上的限制，使管理者無法制定最佳決策。 俗語說：「旁觀者清，當局者迷」，因此建議政府在推動委外政策時，應編列足夠的經費，委託相關學術機構或聘請專家學者深入研究，協助蒐集資料，發揮諮詢功能，提供政府選擇較為客觀，又可行性高的簽約外包項目，以提高成效。

３．制定簽約外包統一之法制：簽約外包政策的法制化內容，應包括政策目的，推動的對象、委託方式，推動的機制、作業程序、招標的方式選擇、人員的處理，經費編列及管制考核等規定，以作為政府各機關推動簽約外包的最高指導原則及政策方向。

４．成立「委託外包專案小組」專責推動：委託外包案因素頗為複雜，處理上也特別困難，由跨局處之專責推動組織，邀集相關機關及民間專家學者民意代表、各社團代表成立臨時任務小組，檢討整體推動計畫，並提供指導業務及協助確定方向，建立法制環境，減少推行的疑難及困擾，避免各機關自行摸索，錯失或延緩委外之時機，或因本位主義，追求自身利益，造成協調失靈的現象。

５．                建立簽約外包管制考核制度：應由政府研究發展考核主管機關列入專案管制計畫，並由該政府人事主管機關會同相關機關及邀請專家學者組成評鑑小組實施評鑑，並依評鑑結果，列入機關考成的重要指標之一。

６．                規劃辦理簽約外包的專業訓練：簽約外包屬於行政契約行為，涉及之行政法令及招商策略，契約內容之權利，廠商的義務，委託辦理之保證金、租金權利金等計價技術，委託人之對外收費項目及標準，公開競標或甄審的評審過程等技術，由於缺乏辦理之經驗，政府機關行政人員為避免執行簽約外包時觸法圖利的行為，常視簽約外包為畏途，因此有必要規劃定期開辦專業人才訓練班期，結訓人員並列冊作為人力運用之資源。

７．                蒐集國內外簽約外包案例彙編「個案集」：廣泛蒐集目前國內外政府推動簽約外包成效良好的個案，選擇之案例必須代表不同性質之類別，彙成個案集，以作為員工教育訓練之教材，並供各機關推動之參考。