IT肥蝦-經濟&科技&專案管理

風險值多少？

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)風險要素的判別

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

依據上面的矩陣，進一步利用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為專案先導成員對此要項給定機率值中最高與最低的差距。

(3)風險要素的量值。

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

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

公式二 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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