軟體專案管理第十五週課程心得_風險值多少

風險值多少？

12月28日尚文與仕賢同學報告第十四章風險管理之時，正巧班上的一位任職於富X證券的同學，因為27日晚機房起火，正忙著幫忙處理善後，不克與課！這對風險的管理，正是一個絕佳的範例。

在書本中，對於風險的定義為：(公式一)

P：機率、L：損失。

而風險降低比的值為：(管理前之風險損失-管理後之風險損失)/(風險降低所花費的成本)。

看著這些公式，對照著書本中解釋風險與專案的困難或問題的差異說明：

(1)風險是針對未來的事件。

(2)風險的發生及造成的損失均不確定。

(3)風險一旦發生將對專案造成重大或致命性的影響。

未來、不確定、重大或致命性！這是多麼”模糊”與”主觀”的字眼。既然是以後的事，造成的影響又是不確定，這不確定又要重大或致命，這不是在玩文字堆砌嗎？在描述專案風險的經典名著【與熊共舞】之中，對於專案的風險有著不少精彩的討論。在其第二章中說明風險包含兩個要素：(1)一個有可能在未來造成意外結果的事件。(2)意外結果本身。這對這未來的意外結果要如何衡量呢？又如何能得知管理後的意外結果價值如何？

看看書中對於風險的辨識與損失暨機率的評估方法，幾乎全是人為主觀方法的認定與評選，不管是一肥蝦或是一群人！在PMBOK中對於風險屬量性資料的研究提出了：Sensitivity Analysis(敏感度分析)、Excepted Monetary Value(EMV) Analysis(期望貨幣價值分析)、Modeling and Simulation(模型與模擬)這三種方式。也許常有人聽說用蒙地卡羅模擬跑一下，不就知道了風險值！但是以上方式都有一個很重要的基礎：瞭解風險的要項，以及其可能的機率分佈樣貌。不管是蒙地卡羅模擬、或是決策樹、或是迴歸，這些都是基於以往的歷史資料，或者是假設為一種機率分配型態，就有著衡量不確定性的不確性內涵於其中。

舉例而言，相對於專案風險值的計算，財務金融領域對於風險值是有著比較明確與完整的方法，雖然該等計算方式仍不脫於歷史經驗與機率理論，但因為有著國際性組織－國際清算銀行下的巴塞爾銀行監理委員會(BCBS)，定義了相關的規範－巴塞爾協定，因此金融業者之間對於風險有著共通性的語言與定義。在巴塞爾協定中將金融風險區分為信用、市場與作業之外，還有著更難衡量的其它風險－信譽風險、策略風險、受託人風險。協定中除了定義的風險要項，並且提供由淺入深的階段性計算方法，信用風險有：Simplified Standardized、Standardized Approach、Foundation Internal Ratings-Based Approach、Advanced Internal Ratings-Based Approach；市場風險有：Standardized Approach、Internal Models Approach；作業風險有：Basic Indicator Approach、Standardized Approach、Advanced Measurement Approach。上述該等方法，其實都源自於大型國際性金融單位的經驗與認知所推演而出，因此一些非歐美系、或者地區性小型金融單位於推展之時不免有諸多難處。但是，但是2007年的全球行次貸危機還是使得一些大型金融機構應聲而倒，因此可證，基於歷史資料或者主觀經驗的風險值仍隱含著若干未知的風險，因此風險的價值估算目前仍是一個難解的議題。

就算如此，但肥蝦以為，風險的估算仍是軟體專案不可或缺的重要部分，就像Edward De Bono在【在「沒有問題」裡找問題】一書中第十講中所說的：「計畫是依照現實狀況及推斷當下潮流而擬定的，在快速運轉的世界裡，計畫幾乎總會有失誤。…計畫的不可靠不能作為忽視它的藉口，而是要視為一種提醒我們計畫不能做得沒彈性的警訊。做計畫時要考量到狀況會改變，同時也得顧及特定狀況會不會持續。重要的是規畫時就要顧慮到彈性和不確定性。」相較於計畫，風險也是基於經驗、現實狀況，以及推斷當下潮流所進行的估計，也萬不可以因為估計上的誤差，就予以放棄，而是要設法保持風險估計與回應方法上的彈性與穩健性。

在軟體專案的風險衡量上，應該要如何進行呢？目前不管是參考功能點法、快速功能點法、PERT、Riskology、ISO 27005、或者STSC的Guidelines for Successful Acquisition and Management of Software Intensive Systems, Version 3.0 對於軟體專案中風險的估算，都有著參考者需要自行客製化的部分要素，甚至需要設定所可能面對的機率分配，因此風險估算並非是依據特定不變的公式計算，這是一般應有的基本認知。

就肥蝦的經驗與認知，在專案初起之時，風險值的估算與回應，可以依據下述步驟進行：(1)風險要素的判別。(2)風險要素的機率設定。(3)風險要素的量值。(4)風險要素回應的規劃。

在此須先述明，以下的作法與邏輯僅為肥蝦的認知，並未有任何相關文獻與統計的支持，因此分享的目的在提供大家一起集思廣義而已。

(1)風險要素的判別

肥蝦建議風險要素的判別可以先從三個面向，以及參考【與熊共舞】第三章所陳述的不確定性來源作以下的風險要項矩陣分類：

面向 議題	已知的未知			未知的未知
	商業觀點	客戶觀點	技術觀點
需求(requirement)	要作的究竟是什麼?
匹配(match)	要如何與使用者，以及其他周邊設備進行互動?
變動的環境(changing environment)	在開發期間，若需求與目標改變的話，該怎麼辦?
資源(resources)	哪些關鍵的專業技術是必備的?
管理(management)	有足夠的管理天份去組織一個具生產力的團隊，維持士氣，低離職率，以及協調眾多錯綜複雜的工作?
供應鏈(supply chain)	都能如期得到開發的其他單位的支援嗎?
政治(politics)	如果動用政治力來影響現實會有什麼效果?對專案最後的成功會造成什麼限制?
衝突(conflict)	不同的利害關係人(stakeholder)的目標彼此衝突時，該如何排解?
創新(innovation)	影響專案最終成果的各種技術和方案有多麼獨特?
規模(scale)	把份量和範圍擴大之後，對專案執行績效的衝擊會有多大?

依據上面的矩陣，進一步利用Rubin Jen於PMI網站所發表的－「Visual Ishikawa Risk Technique(VIRT) – An Approach to Risk Management」的方法，由專案參與的先導者進行悲觀式的風險思考，將思考所得的悲觀因素填入上面的風險要項矩陣表。

Visual Ishikawa Risk Technique(VIRT)是一個以圖形呈現與分類風險因子的工具。以圖形陳列出高階的風險群組與風險因子，在依據每個高階的風險因子，繼續探究其下的相關風險要項，其間用實線描繪出風險因素間直接的關聯性，如此可以呈現出一個風險的整體架構，也易讓人具有完整的印象。其步驟為－(1)建立風險分解結構(Create the RBS)。(2)鑑別專案失敗要點(Identify Points of Failure)。(3)鑑別顯著的障礙(Identify Significant Obstacles)。(4)分解專案失敗要點至風險細項(Decompose Points of Failure to Detailed Risks)。(5)完成後續的風險管理活動(Complete Following Risk Management Activities)。(6)運用至持續狀態報告與重複狀態顯示(Apply to Ongoing Status Reports and Recurring Status Presentations)。

(圖一)

肥蝦深覺VIRT是一個不錯的鑑別、追蹤與重新檢視風險的好工具，如果再以虛線描述之間的不同群組或類別間風險因素的互動，如此將更能助益於之後的風險回應計劃的討論與建構。本文所展現的圖形，即是肥蝦稍加修改過的圖形表示法。但是麻煩的是會把圖形弄得非常複雜，因此可以利用MS Visio的圖層屬性去分層表示以保持圖形的明確性與可見性。

(2)風險要素的機率設定。

接著，專案的先導成員可以主觀的設定各風險要項的發生機率，每一項機率值為，此要項發生對專案違約或失敗的可能性。所有的機率總合不必為一，但是必須能有效的說明出理由。機率給定的方式可以取所有人的給定值的均數或眾數；但是需要標註所有人給定機率值的上下數字間的差距。此時，如果公司內部或者外界相關單位有著可以參考的數據或量表，可以提供予成員參考，但不可就用外部的資源源數據就具以填入要項表格之中，因為每個企業、部門、或者專案，都有相對的獨特性，因此任何外部資料僅供於參考即可。

面向 議題

已知的未知

未知加權

商業觀點

客戶觀點

技術觀點

聯集

要項

P

R

要項

P

R

要項

P

R

要項

P

R

需求(requirement)

…

上表中的P代表該項的發生機率的均數；R為專案先導成員對此要項給定機率值中最高與最低的差距。

(3)風險要素的量值。

有了風險要項，以及機率，接著要如何衡量每個風險要項？其實每個要項可能的損失額為何，是一個難以衡量的價值。因此肥蝦以為就以專案的報價或者該專案的合約金額為所以計算風險值的基礎價值。一來，可以簡化風險值的計算。二來，經由一些文獻上的實證，早期的風險或失誤，所導致的修正成本隨著專案的進行而成幾何級數的增加。

因此，對於公式一之風險定義值中，L將統一為專案的合約金額，但是必須再加入對於風險機率差距的權重，以及針對十項不確定性來源中可能未知的風險部分，此就是PMBOK中所提到的unknown risks，這部分因為是未知的風險，所以可以依據主觀的經驗設定，根據以往的專案經驗，根據業界參數值的調整後結果，或者就照著已知風險估計的分配狀況。因此風險的定義值可修改為為：公式二

其中的j為不確定性類別，i為類別中的風險要項，R為該風險要項中的機率全距，UP為不確定性類別中unknown risk的比率權重。

(4)風險要素回應的規劃。

接著對於風險的回應，除了參考書中所描述的風險減緩策略－風險預防、風險解決、風險避免、風險分散、風險移轉的部分外，也可以參在PMBOK上所定義的幾種方式：

風險回應策略類別	風險回應作業
Strategies for Negative Risks or Threats	-Avoid(避免) -Transfer(移轉) -Mitigate(減緩) -Accept(接受)
Strategies for Positive Risks or Opportunities	-Exploit(利用) -Share(分享) -Enhance(擴大) -Accept(接受)
Contingent Response Strategy

更重要的是，可以根據專案開發的模式與時程，決定風險策略的執行與檢核時點。比如於建議書的撰寫中就必須考慮閃躲的風險，在專案規劃階段就必須強調的風險與對應的工作項目，在專案執行間根據風險的trigger所驅動的風險回應作業…等等。

肥蝦以為，風險回應的即時性、有效性與彈性遠重於風險回應的完整性。針對規劃階段對於風險回應的思考，可以參考【與熊共舞】第三章所陳述的內容：

(1)為什麼沒有XXX,專案就無法完成?

(2)為什麼XXX是在要徑(critical path)上?

(3)沒有其他替代方法來取代XXX的功能嗎?

(4)當XXX無法如期完工，為何不動用這些替代方法讓專案目標達成?

(5)不能重新設計(replan)讓替代方法發生功能嗎?

(6)不能在執行特定活動前，就先重新設計嗎?

(7)之前有察覺到XXX的延誤會是一個潛在的風險嗎?

(8)先前類似XXX的活動都不曾延誤嗎?

(9)之前類似的專案中有任何歷史記錄嗎?

(10)開發團隊有參考先前類似專案的經驗嗎?如果有參考過有從中學到什麼嗎?

(11)那專案的管理階層上有採納建議嗎?

(12)對可能造成的延誤，專案團隊有提出足夠的警告嗎?

風險的處置都需要花費成本，更重要的是風險回應的重點不再於消除專案所有的風險，而是要能明瞭我們需要負擔哪些風險，以及所能承受的風險。就像那巴塞爾協定－所有風險的計算轉為要求金融單位計提的自有資本，惟有明瞭自我的風險承受度，才能確保所承作專案的安全性。

以上是肥蝦對於專案初起階段計算專案風險值的簡略想法，疏漏或錯誤在所難免，還請 先進指正！

檢視今年，展望百年

轉眼間，秋去冬至，2010年已邁入尾聲計時，民國百年就將到來。檢視肥蝦這一年的目標達成率與成本效益比，實在是令人汗顏呀！今年一年除了養家糊口必要的工作之外，一年來擔任社區的主任委員也是耗費了不少的時間與精力，更因著自己的怠惰，使得個人設定目標的達成上，以及自我知識的充實上更是一事無成。在專案管理交流論壇上的線上讀書會的導讀只完成了一本Edward De Bono所著，吳春諭先生所譯的【在沒有問題裡找問題(Powerful Tools to Transform Your Thinking)】；在專案管理智能的學習上，只參加兩次Bryan & Joe所舉辦的workshop、PMI-TW所舉辦的「2010台北國際專案管理論壇」、熊博士的「專案經理軟技能學習」；在IT技能的學習上，也只能參加些微軟、甲骨文、優利的一些研討活動；其他一切所設定的資安、財務金融專業，以及語文的學習上，都是付之闕如，甚者更是半途而廢。

今年在學習上最愉悅之事，大概是參加了Bryan & Joe舉辦的Workshop，認識了這兩位”清新”的專案管理先進，以及他倆所聚攏的一些專案管理學習的粉絲了！從他們身上，肥蝦看到了、也學到了不少的智識與經驗，尤其是不同於現今專案管理教育與顧問市場中的風格與活力，更使肥蝦有著不同的感受。他們以靈活、彈性與活潑的教法，付予了台灣地區專案管理研習課程的不同面貌；更藉由他們的部落格、臉書，宣傳了生活與工作中專案管理的應有內涵，而不是短視應付認證考試的不當態度，真得是讓肥蝦激賞不已。

延續著原有Matt、Erin、小歆、Honda、信輝，五位好友的心力，一同在小歆創建的專案管理交流論壇上結識了雲翔與foolboy，一同分享與討論，更讓肥蝦深受感動。因著時境的變化，與Matt、Erin、小歆、Honda、信輝等雖不似以往般時常見面，但是定期的聚餐與臉書上的溝通，對於他們的情誼，肥蝦深深感謝！

一年來，劉育津老師的教導與協助，同門師兄弟－金田師兄、志中與帝林師弟的相扶互助，班上同學的融洽相處、互相勉勵，也像讓夜空中的星光一般閃爍明亮；尤其是下學期修讀李坤清老師的「軟體專案管理實務」，雖然李老師自稱離開業界參禪多年，但老師的一些思維與看法，以及同學們在課堂上的報告，更讓肥蝦收穫良多。

今年在台灣的IT研討會中，不管是微軟的三螢一雲，或是甲骨文的EXA系列，優利引入了Eclipse、ClearPath等新方案，【雲端】一詞可說是獨領風騷。不管肥蝦個人對於雲端的看法如何！來年，雲端風潮勢必延燒下去，對於雲端上的開發與應用，肥蝦也只能多多努力學習。

展望百年，在學習上，除了努力思考與撰寫論文外；對於IT技能的學習上，肥蝦也得加把勁。在微軟Dot NET的框架，雲端上的相關開發技術，Java平台的應用上，都必須多花費點心力；業務上，所應要關心的個資法、IFRS、風險管理、商業智慧等議題，也要持續關心；當然，在專案管理的專業上，也要能更進一步才行。此外，因應著工作的變遷，可能有著職位上的異動，肥蝦恐將面臨不同著迥於以往只以系統分析與專案管理的領域。

明年首要研修的課程，預計將報名金研院有關IFRS的相關課程，尤其金融商品的會計處理，從反應市場風險的真正公平價值入手，以買賣商品實務目的－交易目的、備供出售、持有至到期的觀念，到外幣持有之功能性區別，肥蝦必須再加強瞭解的程度。在專案管理方面，軟體需求工程的部分，實作多年，但只有初步的認知，但都未有學習相關的嚴謹課程，因此也計劃排入明年的學習課程；Primavera專案管理工具，肥蝦一直是緣鏗一面，有時間也想拜見拜見這有名的軟體系統。當然，最重要的還是完成世新的學業，當然追求文憑不是肥蝦的惟一目的，但入寶山怎可空手歸，下學期除了論文外，也要再選個一、二門課程來修讀。

雖然每次年末，對自我未來都有諸多的期許，但身胖性懶，每次都是徒呼負負！值此99年的最後一天，還是不免循於往例，再設定自己的目標！也心願各位朋友心想事成，萬事如意，事事順心！新年快樂！

『統計 Versus資料探勘』之我見

昨天在床上看論文第二章文獻探討要用的英文期刊，一時煩悶下就拿了本【科學人雜誌(第105期)】來看！其中有一篇短文「失之毫釐，差以千里」，講得是統計抽樣誤差的問題，內容是說美國在調查軍中同性戀的比例，因此進行軍中同性戀的調查。這直覺看起來好像沒有問題，可是卻會導致情況為真(異性戀)但被誤認為假(同性戀)的型一誤大於情況為假(同性戀)但被誤認為真(異性戀)的型二誤高的統計問題，就是所謂的非對稱性族群數目，或稱類別資料不平衡(class-imbalanced)的問題。一時之間突然想到曾在第132號數學傳播季刊看到的一篇統計思維文章，以及同學在上資料探勘之時常會詢問的問題－「統計跟資料探勘差在哪裡？」

肥蝦不是一個專業的統計學家或者專研資料探勘的學者，因此一些想法並不一定正確，但寫此文的目的只想拋磚引玉，順便也能確認自己的思維與認知是否正確！

【數學傳播季刊】統計思維乙文的作者為黃文璋教授，任教於高雄大學應用數學系，是一個聲譽卓著、著作等身的統計專家。該文除了詳細說明統計的觀念之外，對於一些重要的概念更是旁徵博引一些文學典故，一文讀來有讓人不忍釋手之快。文章一開頭就引用了馬克吐溫的名言：「There are three kinds of lies: lies, damned lies, and statistics.」(有三種類型的謊言：謊言、可惡的謊言跟統計。)文中也說明統計能達到的作用：(1)在允許誤差下的機率保證。(2)允許誤差下的無罪推定。因此機率跟誤差是為統計學裏的兩大支柱，黃教授並根據統計學的六項要點─善用資訊、了解變異、相信機率、合理估計、無罪推定、紙上談兵─逐一說明。本文可說是字字珠璣，要肥蝦寫出心得，真得就只能把文章照抄一遍了！

關於資料探勘這門較之統計，完全可說是一門新興學問的學門而言，肥蝦也只修過劉育津老師的一學期課程，所知實在非常有限！但還是自言不慚的將自己的想法與心得班門弄斧一下。資料探勘在維基百科中的解釋為：「a branch of computer science and artificial intelligence, is the process of extracting patterns from data. Data mining is seen as an increasingly important tool by modern business to transform data into business intelligence giving an informational advantage.」這裡也僅僅是概要的說明它是計算機科學與人工智慧的一支，是一個從資料中萃取型態的程序。在Jiawei Han，Micheline Kamber與Jian Pei所著【Data Mining: Concepts and Techniques】一書中說：「Simply stated, data mining refers to extracting or "mining" knowledge from large amounts of data.」意即從大量資料中萃取或挖掘出知識。

由於資料探勘與統計在某些方法或名詞上非常接近，甚至相同，因此常讓人容意混淆。比如，維基百科上說的資料探勘一般包括四項工作：Clustering(叢集)，Classification(分類)，Regression(迴歸)，Association rule learning(關聯)這四者在推論統計中也是常見的名詞；更甚者，在一些統計概念的介紹資料中也把資料探勘置於統計學範疇領域之內。

在修讀肥蝦的指導老師劉育津教授的資料探勘的課堂上，老師也引了Berry and Linoff於1997年所著的【Data Mining Techniques: for Marketing, Sales, and Customer Support】的文句，渠等認為一般分析報告是提供了「後見之明」(hindsight) ，統計分析提拱了「先機」(foresight) ，而資料探勘則提供了「洞察力」(insight) ，也就是資料探勘能看到事件中所隱藏的訊息。但在經濟新潮社出版李弘元先生所翻譯日本岡嶋 裕史所著的【從資料中挖金礦】一書中對於統計與資料探勘有一段概略分別的說明：「統計分析的學問體系是在資料成本很高的時代被建立的。那是一種嘗試以最少的資料量，來探索世界的學問體系。反觀在資訊爆炸的現在，資訊便宜且唾手可得。以往不能或無法當作分析對象的資料都變得可以處理，也就是擴大了可處理對象的範圍，同時，分析的深度也得以增加。」因此「資料探勘的本質不在於技巧的翻新，而在於準備資料的質與量上。」

就以上的看法，肥蝦以為，兩者的重點在於因為資料的來源與數量，因此有著理論上的差距。想想現在正在進行的人口普查，如果是普查獲得的實際資料，那就不用在基於受限於資料源，而運用機率與假設，進行統計的抽樣。因此資料量與代表性就是兩者學門間的差異所在。但在這要澄清的一點是，如果我們是以台北市的所有人口普查資料來推測全台地區的某些現況或趨勢，這不管是就統計方法或是利用資料探勘，在都有利用部分(樣本)來推測全部(母體)的問題。當然，用台北市來推估台灣，就肥蝦認為，這實在是一個很差勁的方式，所導致的錯誤是明顯可見的。

但是，如果把母體是放在特X屋的上月銷售狀況，然後想知道上月中最暢銷商品間的關係，如果我們礙於資料的取得成本，是抽樣的取幾家分店的銷售資料；跟使用公司資料庫內存放所有分店的上月所有完整銷售明細資料，那在學理與方法上就應該有些不同。統計上需先假設或預設一些情境或認知，比如要抽取那幾家分店，那負責的人員可能會基於自身的經驗與知識，選擇以往月營收為全分店平均值的店面；但是資料探勘就沒有這個問題，反正我是處理所有分店的資料。如果在此情況下，有人用資料探勘出的趨勢或規則，再佐以統計去驗證，那就好像都知道你一家所有人的月收入後，再考慮用一家中父親的收入來驗證全家人的收入是否正確！這在理論上跟實際上都是矛盾的。那如果是要預測下個月的情況是否與上個月一樣，那不管上月的規則是從統計、或者資料探勘中得出，這都有不確定性的問題。

因此肥蝦把統計跟資料探勘看成是，統計是先認知出特定規則再進行驗證；資料探勘是先找出所有可能，再行就可能中認知出規則。那至於是統計好，或是資料探勘好？那還是取決於成本！你所要瞭解表象背後事實可能的效益與找出這事實可能成本間的比較！那為何是事實可能呢？因為不管是統計或是資料探勘，在絕大多數的情況下，還是多少有一點認知跟主觀的問題，除了上帝之外沒人知道表象後的真正事實！現在在量子力學的架構中，可能上帝也無法事先確知事實的結果了。

軟體專案管理第十四週課程心得_軟體專案委外之深思與迷思

軟體專案委外之深思與迷思

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)的費用。甚者，完全忽視了資訊背後隱藏的是商業知識，資訊基礎靠的是商業邏輯。

因此銀行要想在知識經濟的時代獲取高額的利潤，就要擁有卓越的商業知識，快速應變的能力，以及獨特的商業智慧，而這一切的一切就隱藏在銀行所規劃與運用的資訊系統之中，因此銀行要將資訊委外，所可以委外者、也適合外包的，是那日復一日、毫無知識發展的部分，對於要能配合銀行發展所要具備的商業智慧，是要設法掌握在自己手中才是。

以上為肥蝦對此的心得分享，因為肥蝦的經驗與智識實屬有限，還請 先進們多給予指導！