整合專案中的風險管理 （轉）
Clearnet公司是國外一家知名的IP電話裝置廠商。它在國內擁用許多電信運營商客戶。Clearnet主要透過分銷的方式發展中國的業務，由國內的合作伙伴和電信公司簽約並提供具有增值內容的整合服務。
2000年，國內一家省級電信公司（H公司）打算上某專案，經過釋出RFP（需求建議書）以及談判和評估，最終選定Clearent公司為其提供IP電話裝置。立達公司作為Clearent公司的代理商，成為了該專案的系統整合商。立達公司是第一次參與此類工程。H公司和立達公司簽訂了總金額近1000萬元的合同。李先生是該專案的專案經理。
該專案的施工週期是三個月。由Clearnet負責提供主要裝置，立達公司負責全面的專案管理和系統整合工作，包括提供一些主機的附屬裝置和支援裝置，並且負責專案的整個運作和管理。Clearnet和立達公司之間的關係是外商通常採用的方式：一次性付賬。這就意味著Clearnet不承擔任何風險，而立達公司雖然有很大的利潤，但是也承擔了全部的風險。合同是固定總價的分期付款合同，按照電信業界慣例，10%的尾款要等到系統透過最終驗收一年後才能支付。
3個月後，整套系統安裝完成。但自系統試執行之日起，不斷有問題暴露出來。H公司要求立達公司負責解決，可其中很多問題涉及Clearent的裝置問題。因而，立達公司要求Clearent公司予以配合。Clearent也一直積極參與此專案的工作。
然而，李先生發現，立達對H公司的承諾和技術建議書遠遠超過了系統的實際技術指標，這與Clearent與立達的代理合同有不少出入。立達公司也承認，為了競爭的需要，做了一些額外的承諾。這是國內公司的常見做法，有的公司甚至乾脆將尾款不考慮成利潤，而收尾款也成了一種專職的公關工作。這種做法實質上增加了專案的額外成本，同時對整個的商業行為構成潛在的誠信危機。
對於H公司來說，他們認為，按照RFP的要求，立達公司實施的專案沒有達到合同的要求。因此直至2002年，H公司還拖欠立達公司10%的驗收款和10%的尾款。立達公司多次召開專案會議，要求Clearent公司給予支援。但由於開發週期的原因，Clearent公司無法馬上達到新的技術指標並滿足新的功能。於是，專案持續延期。為完成此專案，立達公司只好不斷將Clearenet公司的最新升級系統（軟體升級）提供給H公司，甚至派人常駐在H公司（外地）。
又經過了3個月，H公司終於透過了最初驗收。在立達公司同意承擔系統升級工作直到完全滿足RFP的基礎上，H公司支付了10%的驗收款。然而，2002年底，Clearent公司由於內部原因暫時中斷了在中國的業務，其產品的支援力度大幅下降，結果致使該專案的收尾工作至今無法完成。
據瞭解，立達公司在此專案上原本可以有250萬元左右的毛利，可是考慮到增加的專案成本（差旅費、溝通費用、公關費用和貼現率）和尾款，實際上的毛利不到70萬元。如果再考慮機會成本，實際利潤可能是負值。
導致專案失敗，尤其是專案預期的經濟指標沒有完成，這是非常遺憾的事情。專案失敗或沒有達到預期的經濟指標的因素有很多，其中風險管理是一個極為重要的因素。
在上面的案例中，專案的利潤值最後可能是負值就是這樣的情況。而該專案最終失敗的原因主要在於風險控制和風險處理機制。
在很多IT專案中，由於競爭和其他原因造成了風險過度集中在某一個相對弱勢的角色身上。在本案例中，立達公司就處於這樣的境地：一方面它需要依賴代理Clearent公司的產品生存，另一方面要它還必須要滿足使用者的具體需求。
我們知道，專案經理有識別和處理風險的責任。通常，專案經理在運作這樣的專案時，要充分考慮到自己公司所處的地位，充分發揮自己的作用，平衡各方的利益。
事實上，專案管理知識體系中關於風險管理方面有非常詳細的論述。不過，在實際工作中，如果完全照搬國外專案管理的風險識別和控制理論，是很難達到較好的效果。
一般來說，對於國內公司的專案經理來說，除了理解專案管理知識體系中的理論外，還需要在實踐中進行總結。在這裡，介紹一些容易被忽視的地方。
籤合同前的“需知”
一般情況下，如果專案經理在專案合同簽訂以前加入專案，可以充分利用專案採購管理一章的知識，瞭解自己公司在專案中的位置，對買方提出的RFP認真回答，規避潛在的風險，這是非常重要的。對於RFP中過高的要求不能完全滿足時，應充分說明，並在以下幾個方面有充分的準備和考慮：
1．合同的型別。通常，在IT專案中，代理商與終端使用者的合同型別是很難改變的固定價格合同，但對代理商和裝置商之間的合同是有很多講究的。代理商和國外供貨商一般是透過信用證付款，但很多時候，為了拿到訂單，供貨商通常給予代理商一定的信用額度和付款方式的優惠。代理商應充分利用這一利害關係，在合同簽訂以前決不能輕易讓步。
2．專案實施方對專案的熟悉程度。通常情況下，做一個成熟專案的風險小，而做新專案的風險高。在本案例中，立達公司是第一次進行類似的專案，並不完全瞭解其中的風險，更無可利用的歷史資料。因此，在這種情況下，最好採用“讓利於人，風險共擔”的策略。具體做法是，將已經識別的具有風險的部分外包(即風險轉移)，或者單獨與供貨商簽訂補充合同。這樣做可能損失了部分利益，但降低了風險，並且減少了很多額外投入。
3．具有明確的規範（Specification），包括設計規範（Design）、功能性規範（Functional）、效能規範（Performance）。明確的規範是識別風險和規避風險的前提條件。如果已經具有一定的歷史資料，可以採用頭腦風暴的方式對規範加以確認和識別，這項工作可與風險識別同時進行。
風險的預警和量化
在專案的進行過程中，專案經理和專案的擁有人要將風險管理納入日常工作的重要步驟。要明確成本與風險、成本與時間的關係。在制定完善的風險管理計劃的基礎上，從以下幾個方面入手。
1．建立管理風險預警機制。對於風險集中的一方，建立管理風險預警是風險管理計劃的重要補充。這裡的預警是指對有可能超出專案經理管理範圍的風險事件的預警。預警機制可由低到高，並由定期的專案聯席管理（多方）會議討論處理。這樣可以減少處理風險事件的響應時間；同時，使高層管理者能夠及時介入，處理可能產生的風險。
2．風險的量化。之所以單獨將風險的量化加以論述，是因為很多情況下，專案經理的確已經對風險進行了識別，並採取了應對措施，但並未對此風險帶來的影響進行量化（通常可以以貨幣或者時間損失加以估算）。量化過的風險是專案經理採用相應對策的前提。像在本例中，立達公司瞭解Clearent公司升級軟體不能按時提供，這本身就需要量化。這個風險帶來的就是10%的驗收款和10%尾款的不能按時支付。如果一開始，立達公司能夠將付款和風險對應起來，就知道該風險是管理風險，並且是不能夠接受的。
總之，風險集中的專案管理起來是極為複雜的。要儘量在第一時間把事情考慮好，不能指望風險小的一方替風險大的一方承擔很多責任。尤其是目前進入中國市場的國外企業很多，情況複雜，IT市場的變化有時很難預測，更應該注意風險帶來的影響。[@more@]
2000年，國內一家省級電信公司（H公司）打算上某專案，經過釋出RFP（需求建議書）以及談判和評估，最終選定Clearent公司為其提供IP電話裝置。立達公司作為Clearent公司的代理商，成為了該專案的系統整合商。立達公司是第一次參與此類工程。H公司和立達公司簽訂了總金額近1000萬元的合同。李先生是該專案的專案經理。
該專案的施工週期是三個月。由Clearnet負責提供主要裝置，立達公司負責全面的專案管理和系統整合工作，包括提供一些主機的附屬裝置和支援裝置，並且負責專案的整個運作和管理。Clearnet和立達公司之間的關係是外商通常採用的方式：一次性付賬。這就意味著Clearnet不承擔任何風險，而立達公司雖然有很大的利潤，但是也承擔了全部的風險。合同是固定總價的分期付款合同，按照電信業界慣例，10%的尾款要等到系統透過最終驗收一年後才能支付。
3個月後，整套系統安裝完成。但自系統試執行之日起，不斷有問題暴露出來。H公司要求立達公司負責解決，可其中很多問題涉及Clearent的裝置問題。因而，立達公司要求Clearent公司予以配合。Clearent也一直積極參與此專案的工作。
然而，李先生發現，立達對H公司的承諾和技術建議書遠遠超過了系統的實際技術指標，這與Clearent與立達的代理合同有不少出入。立達公司也承認，為了競爭的需要，做了一些額外的承諾。這是國內公司的常見做法，有的公司甚至乾脆將尾款不考慮成利潤，而收尾款也成了一種專職的公關工作。這種做法實質上增加了專案的額外成本，同時對整個的商業行為構成潛在的誠信危機。
對於H公司來說，他們認為，按照RFP的要求，立達公司實施的專案沒有達到合同的要求。因此直至2002年，H公司還拖欠立達公司10%的驗收款和10%的尾款。立達公司多次召開專案會議，要求Clearent公司給予支援。但由於開發週期的原因，Clearent公司無法馬上達到新的技術指標並滿足新的功能。於是，專案持續延期。為完成此專案，立達公司只好不斷將Clearenet公司的最新升級系統（軟體升級）提供給H公司，甚至派人常駐在H公司（外地）。
又經過了3個月，H公司終於透過了最初驗收。在立達公司同意承擔系統升級工作直到完全滿足RFP的基礎上，H公司支付了10%的驗收款。然而，2002年底，Clearent公司由於內部原因暫時中斷了在中國的業務，其產品的支援力度大幅下降，結果致使該專案的收尾工作至今無法完成。
據瞭解，立達公司在此專案上原本可以有250萬元左右的毛利，可是考慮到增加的專案成本（差旅費、溝通費用、公關費用和貼現率）和尾款，實際上的毛利不到70萬元。如果再考慮機會成本，實際利潤可能是負值。
導致專案失敗，尤其是專案預期的經濟指標沒有完成，這是非常遺憾的事情。專案失敗或沒有達到預期的經濟指標的因素有很多，其中風險管理是一個極為重要的因素。
在上面的案例中，專案的利潤值最後可能是負值就是這樣的情況。而該專案最終失敗的原因主要在於風險控制和風險處理機制。
在很多IT專案中，由於競爭和其他原因造成了風險過度集中在某一個相對弱勢的角色身上。在本案例中，立達公司就處於這樣的境地：一方面它需要依賴代理Clearent公司的產品生存，另一方面要它還必須要滿足使用者的具體需求。
我們知道，專案經理有識別和處理風險的責任。通常，專案經理在運作這樣的專案時，要充分考慮到自己公司所處的地位，充分發揮自己的作用，平衡各方的利益。
事實上，專案管理知識體系中關於風險管理方面有非常詳細的論述。不過，在實際工作中，如果完全照搬國外專案管理的風險識別和控制理論，是很難達到較好的效果。
一般來說，對於國內公司的專案經理來說，除了理解專案管理知識體系中的理論外，還需要在實踐中進行總結。在這裡，介紹一些容易被忽視的地方。
籤合同前的“需知”
一般情況下，如果專案經理在專案合同簽訂以前加入專案，可以充分利用專案採購管理一章的知識，瞭解自己公司在專案中的位置，對買方提出的RFP認真回答，規避潛在的風險，這是非常重要的。對於RFP中過高的要求不能完全滿足時，應充分說明，並在以下幾個方面有充分的準備和考慮：
1．合同的型別。通常，在IT專案中，代理商與終端使用者的合同型別是很難改變的固定價格合同，但對代理商和裝置商之間的合同是有很多講究的。代理商和國外供貨商一般是透過信用證付款，但很多時候，為了拿到訂單，供貨商通常給予代理商一定的信用額度和付款方式的優惠。代理商應充分利用這一利害關係，在合同簽訂以前決不能輕易讓步。
2．專案實施方對專案的熟悉程度。通常情況下，做一個成熟專案的風險小，而做新專案的風險高。在本案例中，立達公司是第一次進行類似的專案，並不完全瞭解其中的風險，更無可利用的歷史資料。因此，在這種情況下，最好採用“讓利於人，風險共擔”的策略。具體做法是，將已經識別的具有風險的部分外包(即風險轉移)，或者單獨與供貨商簽訂補充合同。這樣做可能損失了部分利益，但降低了風險，並且減少了很多額外投入。
3．具有明確的規範（Specification），包括設計規範（Design）、功能性規範（Functional）、效能規範（Performance）。明確的規範是識別風險和規避風險的前提條件。如果已經具有一定的歷史資料，可以採用頭腦風暴的方式對規範加以確認和識別，這項工作可與風險識別同時進行。
風險的預警和量化
在專案的進行過程中，專案經理和專案的擁有人要將風險管理納入日常工作的重要步驟。要明確成本與風險、成本與時間的關係。在制定完善的風險管理計劃的基礎上，從以下幾個方面入手。
1．建立管理風險預警機制。對於風險集中的一方，建立管理風險預警是風險管理計劃的重要補充。這裡的預警是指對有可能超出專案經理管理範圍的風險事件的預警。預警機制可由低到高，並由定期的專案聯席管理（多方）會議討論處理。這樣可以減少處理風險事件的響應時間；同時，使高層管理者能夠及時介入，處理可能產生的風險。
2．風險的量化。之所以單獨將風險的量化加以論述，是因為很多情況下，專案經理的確已經對風險進行了識別，並採取了應對措施，但並未對此風險帶來的影響進行量化（通常可以以貨幣或者時間損失加以估算）。量化過的風險是專案經理採用相應對策的前提。像在本例中，立達公司瞭解Clearent公司升級軟體不能按時提供，這本身就需要量化。這個風險帶來的就是10%的驗收款和10%尾款的不能按時支付。如果一開始，立達公司能夠將付款和風險對應起來，就知道該風險是管理風險，並且是不能夠接受的。
總之，風險集中的專案管理起來是極為複雜的。要儘量在第一時間把事情考慮好，不能指望風險小的一方替風險大的一方承擔很多責任。尤其是目前進入中國市場的國外企業很多，情況複雜，IT市場的變化有時很難預測，更應該注意風險帶來的影響。[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-938093/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- IT專案管理中的風險控制（轉）專案管理
- 專案風險管理（轉）
- 風險管理在施工專案管理中的應用（轉）專案管理
- 小議ERP專案中的風險管理(轉)
- ERP專案的風險管理（轉）
- 工程專案管理中的風險分析與防範（轉）專案管理
- 專案管理過程之風險控制 （轉）專案管理
- STC訂單專案風險管理（轉）
- 專案管理過程之風險控制(轉)專案管理
- 專案風險管理
- 軟體開發專案的風險管理(轉)
- ERP專案的風險控制與管理（轉）
- 淺談房地產專案的風險管理（轉）
- PFMEA在專案風險管理中的應用
- 專案風險管理與蒙特卡羅方法（轉）
- 建築專案合同管理風險防範（轉）
- 專案風險緩解、監控和管理（轉）
- 科研專案管理的成功標準和風險分析（轉）專案管理
- 淺論軟體外協專案的風險管理(轉)
- 實行專案風險經營 提高專案管理水平 （轉）專案管理
- 實行專案風險經營 提高專案管理水平(轉)專案管理
- 系統整合專案實施的管理(轉)
- 專案整合管理
- 管理軟體開發專案關鍵風險 （轉）
- FMEA技術在IT專案風險管理中的應用
- 專案風險管理：透過五步降低風險
- 如何更有效管理專案風險？
- 什麼是專案風險管理？要如何執行風險管理？
- 一．專案整合管理
- TL,你是如何管理專案風險的？
- 專案（Explore）總結之專案風險管理
- 風險管理是軟體專案管理的第一管理專案管理
- 專案管理中溝通的作用（轉）專案管理
- 企業中的專案管理1（轉）專案管理
- 企業中的專案管理2（轉）專案管理
- 企業中的專案管理3（轉）專案管理
- 企業中的專案管理4（轉）專案管理
- 企業中的專案管理5（轉）專案管理