軟體專案委外之深思與迷思
12月21日士東與玉蓮同學報告第十三章外包管理。在專業分工的現在，不管是為了書中所言的：「維持核心能力、小型化的趨勢、降低成本、爭取時效、取得新技術、解決資訊中心無法滿足的需求…」等原因，或者其他理由，一個中、大型的軟體專案，大都是業主與一些廠商共同合作來完成。在先不討論原合約甲方的立場下，對於委外合約的上包或下包角色，肥蝦都有過些許的經驗。如果是第一次與他人合作開發專案，不管是上包或下包，對於開始合作的態度與模式都需要一段時間的磨合期。尤其是跟國外的廠商合作之時，一般上這磨合期間的互動，更是相對的痛苦！就以往的經驗，上包若是基於要設法將原有組織人員進行縮減或只圖降低成本，下包商就真得不好做！記得肥蝦有次擔任委外下包的專案經理，因為原廠的合作人員聽聞公司與我們合作的企圖就是要把他們的工作以後轉包給我們，然後降低成本，可想而知這案子這專案經理做起來真得很窩囊。不管是上包有無道理，每次主管跟我去上包開會都是我被釘，都是我的錯！然後主管出來後才給我摸摸頭，做起來真得很XX。其實除了第一次的合作，不然都像肥蝦在修讀企管所的作業管理中所介紹【供應鏈】機制。而且，若主要是以風險轉移或控制為考量重點，在其他如價格、能力等能配合下，一般廠商如果要將工作委外，基本上都會先尋求以往有合作經驗的廠商。
委外作業的程序，以及應該注意的要項
這裡，肥蝦想先討論一下的是委外作業的程序，以及應該注意的要項。補充的資料是PMBOK的第十二章，以及金管會下的金融檢查局九十四年所頒行的「金融機構作業委託他人處理內部作業制度及程序辦法」中有關資訊委外的部分。後續上，目前檢查局已有新版的檢查手冊，而且目前也在推出新的草案，但是都把委外分攤在各相應的手冊中，因此肥蝦就九十四年的辦法進行討論。
書本所列的外包程序如【圖一】所示：
以下肥蝦將書中的程序與PMBOK 2008年版第十二章採購管理的程序整理成下表：
| 軟體專案管理 外包管理 | PMBOK Project Procurement Management |
| 成立外包專案小組 | n 由委託單位共同組成外包專案小組，成員應有足夠的代表性。 n 慎選有能力有經驗的專案負責人並給予充分授權。 | Plan Procurements | The process of documenting project purchasing decisions, specifying the approach, and identify potential sellers. |
| 規劃 | n 訂定外包的目標。 n 決定外包的項目及範圍。 n 蒐集資訊。 n 訂定底價。 n 決定合約計價方式。 |
| 準備需求建議書 | 用來徵求廠商的建議書以找到最佳的合作廠商。 |
| 招標 | 依「政府採購法」第十八條，採購之招標方式，分為公開招標、選擇性招標及限制性招標。 | Conduct Procurements | The process of obtaining seller responses, selecting a seller, and awarding a contract. |
| 決標 | 決標的方式要考慮是否訂定底價、是否採最低價得標等因素。 |
| 履約管理 | 履行合約中所載明承包商應遵守的規定及應盡的責任 ，也要載明非預期事項或爭議發生時的處理方法。 | Administer Procurements | The process of managing procurement relationships, monitoring contract performance, and making changes and corrections as need. |
| 驗收 | 驗收時依據合約書的需求規格、品質標準等，進行驗收。 | Close Procurements | The process of completing each project procurements. |
其實原先在PMBOK 2004年版的採購管理有六個程序，跟目前書中所載較為一致。
| PMBOK 2004採購管理程序 | 程序說明 |
| Plan purchases and Acquisitions | The Plan Purchases and Acquisitions process identifies which project needs can best be met by purchasing or acquiring products, services, or results outside the project organization, and which project needs can be accomplished by the project team during project execution. |
| Plan Contracting | Documenting products, services, and results requirements and identifying the potential sellers. The Plan Contracting process prepares the documents needed to support the Request Seller Responses process and Select Sellers process. |
| Request Seller Responses | The Request Seller Responses process obtains responses, such as bids and proposals, from prospective sellers on how project requirements can be met. |
| Select Sellers | The Select Sellers process receives bids or proposals and applies evaluation criteria, as applicable, to select one or more sellers who are both qualified and acceptable as a seller. |
| Contract Administration | managing the contract and relationship between the buyer and seller, reviewing and documenting how a seller is performing or has performed to establish required corrective actions and provide a basis for future relationships with the seller, managing the contract- related changes and, when appropriate, managing the contractual relationships with the outside buyer of the project. |
| Contract Closure | Completing and Settling each contract, including the resolution of any open items, and closing each contract applicable to project or a project phase. |
其實，不管是六個程序或是四個程序，肥蝦以為委外的重點，可以分為委外合約前、合約、合約後，以及專案後四個階段來討論。以下為上包角色的觀點，但身為下包可以反過來思考。
(一)合約前
所謂「知己知彼，百戰不殆！」要委外前，其實要先思考專案的限制、自己的能耐，以及自己的目標。其中的能耐，除了自有開發的技術、人力與資源外，也要想想自己是否有能力能管控下包廠商！有什麼”眉角”可以防制下包廠商跳過你的掌控私下跟客戶直接承諾！甚至以後直接”整碗端過來吃”！尤其身為一個SI廠商，一個專案所要搭配的軟、硬體廠商不少，在起案之前，各家都為己利，希望把自己的餅畫大；但身為一個上包的專案經理，於這個專案的範圍中如何踩住公司的利益，兩方面間這互動關係中的回應與工作的劃分，對於重要的委外廠商是否需要在合作前要求先行簽下”合作協議書”，口袋中是否還有備援的廠商或方案，這等等要素都是需要在合約前好好思考的！
(二)合約
合約下來就決定了大家的角色跟劇本，因此這合約是很重要的！尤其是$。上包為了控制金流跟轉移風險，基本上都會在自己收到甲方的錢後再把下包的錢轉給他，除非是掌握關鍵技術或資源的合作廠商，不然轉包的合約多是背對背地，並且把付款時點再延後的合約，對於不合作的廠商更要有辦法能透過合約去”刁”他的付款；對於下包所要交付的產出，基本上都要比原合約預定的要早上數週，甚至要求他們要分階段交付。
(三)合約後
合約後的管理是很重要的！尤其劃分好的工作範圍是否能切實履行！肥蝦建議專案經理以介面為管理的主軸，原則上不需要太涉入委外廠商內開發細節，但對於下包應交付的文件與產品要能控管好，在測試之時以介面為準，並且隨時注意下包廠商的動態，客戶對其產出或人員的評價。尤其不准下包商犯下自行跟客戶承諾任何事項，以及跨越專案經理向客戶報告進度的致命錯誤。
(四)專案後
我們常會以往後還有合作機會的方式去吊下包商的胃口。但這也是事實，如果雙方互動良好，建立長久的合作夥伴關係，均能有效減省雙方有形與無形的成本。要注意的是，在合作的形態中，大家是利益均霑，千萬不能讓他們反客為主，更不可把雞蛋都放在一個籠子裡，而且每次的合作報價專案經理還是要再審視。
此外，課文中還題到了合約的型態，PMBOK將合約區別為三種大類型，肥蝦以為PMBOK的分類更為完善。
| PMBOK合約分類 | PMBOK合約類別 | 軟體專案管理 合約類別 |
| 總價(Fixed-Price Contracts) | n 固定總價(Firm Fixed Price, FFP) n 總價加激勵(Fixed Price Incentive Fee, FPIF) n 總價加經濟因素調整(Fixed Price with Economic Price Adjustment, FP-EPA) | n 固定價格(Fixed-Price) |
| 成本補償(Cost-reimbursable Contracts) | n 成本加固定費用(Cost Plus Fixed Fee, CPFF) n 成本加激勵(Cost Plus Incentive Fee, CPIF) n 成本加獎勵(Cost Plus Award Fee Contracts, CPAF) | n 成本加管理費(Cost-Plus Contracts) n 成本加固定管理費用(Cost-Plus-Fixed-Fee) n 成本加激勵(Cost-Plus-Incentive-Fee) n 成本加獎金 (Cost-Plus-Award-Fee) |
| 原材料(Time and Material(T&M) Contracts) | | |
肥蝦以往待過的公司跟客戶也執行過不是總價的合約型態，但偏向是原材料(Time and Material(T&M) Contracts)，客戶就人力開發的部分支付費用，而開發環境與平台則是客戶另行自我購入，所以又有些不同。其中的成本加費用合約的說明，肥蝦建議可進一步參考【專案管理的生活思維】中好友Bryan所寫的一篇”傳說中的成本報酬合約” (http://www.projectup.net/blog/index.php?option=com_content&view=article&id=1532:cost-plus-fee&catid=8:pmp-pm&Itemid=18)。由於Bryan有國外大型專案經理的經驗，加之以往他也確實執行過成本加費用的合約型態。從Bryan文中可發現，採用成本加費用的方式，總包不但要管到下包的費用與成本，對於下包再行分包出去的價格與成本也要能進一步的概算跟掌控。
對於意欲參與PMP考試的朋友，在RITA的【PMP Exam Prep】乙書有一個合約型態對於買賣雙方風險承擔的曲線圖可以作為大家的參考【圖二】：
針對委外應要注意的事項，金管會金檢局曾公告的『金融機構作業委託他人處理內部作業制度及程序辦法』，雖然金檢局已就更新的情勢演變提出辦法，但舊法的精神與內容肥蝦覺得還是有參考的價值。
該法共有二十二條，去頭(辦法來源)去尾(施行日期)後，還有十九條，其間所提到的相關重點，可以了有關委外的重點：
(1)金融機構作業委外設置控管專責單位，有效執行事前及事後相關控管作業程序及明訂其職權行使範圍(第四、六條)。
(2)金融機構訂定客戶權益保障之內部作業及程序，包括委外糾紛處理程序、客戶資訊提供之條件範圍、移轉方法及對受委託機構使用、處理、控管客戶資料之監督方法(第七條)。
(3)金融機構訂定委外內部作業之風險管理原則及作業程序，包括建立風險辨識程序、風險效益分析及緊急應變計畫之擬定(第八條)。
(4)金融機構訂定委外內部作業之內部控制原則及作業程序，包括訂定委外監督管理之作業程序並將其納入整體內部稽核制度內執行、監督受委託機構內部控制及內部稽核制度之建立及執行 (第九條)。
(5)規範委外契約、複委外契約應記載事項內容(第十條)。
(6)明訂金融機構對委外催收受委託機構之查核及管理事項(第十四條)。
(7)規範委外催收契約特別應記載事項內容(第十五條)。
(8)重申金融機構及其委外催收受委託機構違反本辦法相關規定之處置措施(第十七條)。
(9)金融機構辦理作業委外應遵守相關法令，及中華民國銀行商業同業公會全國聯合會訂定之相關業務規章或自律公約及中華民國信用合作社聯合社發布之相關規定(第十九條)。
以上這都可做為研擬委外合約內容之時的參考－事前事後的管控、委外糾紛的處理、資料的管控、委外作業風險的辨識與處理、委外監督與納入自我原有監督的考慮、委外合約應載事項、委外廠商的稽核、法規遵循…等等都需要審慎的考量。
委外成功的要素與委外的迷思
在玉蓮同學所報告的外包成功因素的部分，書中舉列了：(1)良好的目標定位。(2)理性而詳細的評估。(3)慎選外包商。(4)訂定完備的合約。(5)有效的合約管理。(6)激勵。在吳道文先生所著的【專案規劃：資訊概念篇】第七章「RFP撰擬及合約規劃議題」其中有一RFP撰擬程序圖，以及另一RFP擬定主軸定調之三大構面及作業準備建議項目圖，肥蝦有著深刻的印象，爰整合後複繪如【圖三】：
吳先生此幅架構圖，說明了RFP的目標在達成組織在商業、技術與作業面上的交集，一切以達成目標為依歸，RFP的作業需靈活有彈性，更應該先行考量相關的應變計畫或備援措施，並且妥善運用組織的內外部資源。合約雖然需要一再審閱，但就如吳先生指出的RFP不可能一蹴可就，如果雙方玩起諜對諜、互鬥心角，那只要是人寫的東西就絕對不可能沒有隙縫、完全百分之百完美。
配合著書本所說的成功因素，肥蝦以為要有成功的外包成果，就是彼此要能在達成專案目標為共同前提與基礎上，彼此良善的進行互動合作，甲方不可有著像防賊一樣，深怕乙方偷工減料或者會坐享暴利等心態；乙方也必須想著只有甲方達成目標，乙方才能分享一杯羹湯的。這就是老師所說的：「乙方的產品是要替甲方能經由此專案獲得更大的收益。因此甲方的目標是賺大錢，而不是苛扣乙方的利潤。」讓合作的廠商能在他的專業領域中發揮最大的功效，發包商也才能獲致更鉅大的利潤。因此甲方應改秉持的是以效益的觀念來進行委外的作業。
玉蓮同學所舉的那篇期刊” Challenges in execution of outsourcing contracts”(Nagesh Mukunda Rao,ISEC '09: Proceedings of the 2nd India software engineering conference,ACM Request Permissions)，所呈現出的服務提供者(承包商)與客戶(發包商)的作業績效圖【圖四】，其呈現出的差異與結果，讓肥蝦有深刻的印象。
一個委外配合的廠商的績效獲益低於發包商，出大於入的投資期也遠大於發包商。但目前在臺灣地區政府部門的委外合約配合著會計年度大都是一年一期，如此一來委外的廠商幾乎毫無利潤可言，然後承包商又一心期盼著後續能繼續得標的理想預期下，壓低投標的金額；而委外的單位又深怕中、長期的合作會圖利廠商，讓廠商坐擁”暴利” ，又在後續維護合約上配合審計單位的要求，一般上都只有合約5%，使得讓SI廠商必須拿軟體維護費來補硬體的維護費。因此臺灣的軟體資訊產業永遠都在垂死邊緣掙扎，讓有志於發展的廠商很難累積必要的研發資本。在劣幣驅逐良幣的循環之下，造成了兩方雙輸的局面。
此外，書本中也提到外包的迷思，其中列舉了七項要點：
(1)外包不一定能降低成本。
(2)資訊系統外包不是一個單純的自行開發或購買的問題。
(3)麻煩的問題並不會因外包而自動消失。
(4)先進技術的取得有可能但非常昂貴。
(5)資訊系統是企業核心的一環。
(6)政治性的考量會誇大外包的成效。
(7)外包的風險往往比預期高。
在士東同學所報告的Frank Gutierrez and Laurel Evelyn Dyson於第236485號IBMA商業評論上所發表的“Considering the Human Element of Long-Term IT Outsourcing: A Case Study of an Australian Bank”－澳大利亞銀行資訊委外的例子－正可呼應書中所舉出委外迷思的重點。其實此情況，在臺灣也是有例可循。一般的銀行經營者都是認為銀行的主要獲利來自於與客戶的交易互動之中，因此拼命的推出新服務、新商品，一心企盼提高收入，另一面則設法降低成本，以圖極大化中間的利差！因此很多人都把銀行的資訊單位設定為一種像企業清潔打掃般的工作，只要環境整潔在忍受範圍內，不影響員工日常作業下，更乾淨的窗几，也不會帶給銀行更高的收益，因此亟力設法降低資訊成本在銀行總成本中的比例。
士東同學特別在簡報資料中特別說明了交易成本理論暨代理成本理論。交易成本為發包商所追求的是最低的生產成本(Production Costs)和交易成本(Transaction Costs)的總和；代理成本理論則是發包商就監督成本(Monitoring Costs)、束縳成本(Bonding Costs)與殘餘成本(Residual Costs)進行考量，這三者合稱為代理成本。但很多銀行一意降低生產成本(Production Costs)，但卻忘了還有交易成本(Transaction Costs)，或者監督成本(Monitoring Costs)、束縳成本(Bonding Costs)與殘餘成本(Residual Costs)的費用。甚者，完全忽視了資訊背後隱藏的是商業知識，資訊基礎靠的是商業邏輯。
因此銀行要想在知識經濟的時代獲取高額的利潤，就要擁有卓越的商業知識，快速應變的能力，以及獨特的商業智慧，而這一切的一切就隱藏在銀行所規劃與運用的資訊系統之中，因此銀行要將資訊委外，所可以委外者、也適合外包的，是那日復一日、毫無知識發展的部分，對於要能配合銀行發展所要具備的商業智慧，是要設法掌握在自己手中才是。
以上為肥蝦對此的心得分享，因為肥蝦的經驗與智識實屬有限，還請 先進們多給予指導！
