集團客戶業務保障系統項目風險管理研究

【摘要】 文章以上海移動集團客戶業務保障系統建設項目為例，研究項目風險管理方法，以頭腦風暴方式識別風險，引入FMECA方法以及風險可控性參數來分析風險的嚴重程度，并提出了風險應對策略。該研究對項目的順利開展有很大的幫助作用。

【關鍵詞】 風險管理 風險識別 FMECA

一、引言

為了更好的適應集團客戶業務運營需求，上海移動在2013年啟動了集團客戶業務保障系統的建設項目。上海移動集團客戶業務保障系統的建設項目，采用外包的形式，將系統具體的建設工作交予專業軟件公司。由移動方面對項目進行監督。這樣做的好處是，上海移動不需要掌握具體的系統構建技術，由專業公司來負責解決技術問題。而壞處也十分明顯，即項目運作時進展，產生的問題以及建設質量上海移動是無法及時知曉的。只有當出現了嚴重問題影響到產品交付的時候，上海移動才能知道出現了什么問題。因此需要對項目進行有效的管理。

按照PMBOK（Project Management Body Of Knowledge）項目管理知識體系歸類，項目管理涉及十大知識領域。結合上海移動集團客戶業務保障系統項目的特點，風險管理是本次項目需要重點關注的一個領域。本文中，風險管理過程分為風險識別、風險分析、規劃風險應對策略。

二、項目風險識別

在項目啟動以后，項目組以會議的形式，召集項目組成員和軟件公司的項目組成員，以及部分由系統建設經驗的公司員工就本項的可能遇到的風險進行了討論。采用頭腦風暴的方法，收集了項目運營全過程中可能出現的風險事件。這些風險事件按照事件類型來分類，體現了項目全過程會遇到的風險。經過歸納整理，共分為6類。如圖1所示。

三、項目風險分析

對風險的分析主要考慮風險出現的概率和對項目本身的影響。在本項目中借鑒FMECA方法中的CA分析方法來對本項目中的風險進行分析。FMECA （Failure Mode， Effects and Criticality Analysis）是故障模式、影響和危害性分析的簡稱，起源于航空業和美國軍方，現在廣泛應用于航天航空等制造行業。這種分析方法通過逐一分析各組成部分的不同故障對系統工作的影響，全面識別設計中的薄弱環節和關鍵項目，確定每種故障對產品工作的影響，并按故障的嚴重度及其發生概率確定其危害性。

在FMECA方法中的危害性分析（CA） 中，提出了每個故障的風險系數RPN（Risk Priority Number）的概念，數值范圍從1到1000，數值越高，說明風險越高，其對產品的危害影響也最嚴重。影響RPN的因素有：故障模式發生概率等級OPR（Occurrence Probability Ranking），影響嚴酷度等級ESR （Effect Severity Ranking），以及檢測難度等級DDR（Detection Difficulty Ranking）。其計算公式如下：

RPN=OPR×ESR×DDR

在本項目中，可以沿用前兩個參數，即風險發生概率等級和影響嚴酷等級，簡寫仍為OPR和ESR。而檢測難度在本項目中沒有意義。因此本項目提出風險的可控程度等級CDR（Control Difficulty Ranking）。CDR表示在風險產生后，是否有方法或能力對其進行干預和控制，不讓其帶來的壞影響繼續擴大，把該風險對項目產生的影響控制在最低水平。這個參數的分值仍為1-10。于是本項目每個風險的風險系數RPN的公式就變成了：

RPN=OPR×ESR×CDR

其中，OPR，ESR，CDR這三個參數的分值是通過評分產生的。分值從1-10，越高代表越嚴重。為了提升評分的專業性，剔除個體產生的結論偏差。評分方法為德爾菲法（Delphi method）。項目組將經過頭腦風暴提出并匯總整理的風險列表，以及OPR，ESR，CDR三項的評分標準，郵件發送給公司內工程項目領域的專家，以及軟件公司的相關專家，請他們獨立對每個風險因素的OPR，ESR，CDR三項打分。收到各專家反饋后，通過整理歸納，將反饋的意見反饋給各位專家進行下一輪打分問詢。反復幾次后各專家的評分達成一致。最終每一個風險事件的RPN值如表1所示。

從風險級別的分值結果來看。技術方面的風險事件RPN普遍很高，在RPN的排序中，技術方面的風險事件都在前五位以內，說明技術方面的風險在本項目中需要格外注意。需求變更過大這一風險的RPN分值也比較高，因此需要對需求的變更做一定的控制。相對而言外部環境方面的風險事件RPN都比較低，主要是這些風險發生的概率比較低，但是一旦發生，對于項目的打擊是巨大的，很有可能導致項目的失敗。

四、項目風險應對策略

在應對風險的時候，有四種策略選擇：規避、轉移、減輕、接受。

4.1人力資源方面：減輕策略

項目組與上級領導以及軟件公司約定，一旦發生人員變動情況，將指派能力相當甚至更高的人來接替項目工作。這樣能維持團隊的工作水平。此外，所有項目相關人員必須及時記錄自己的工作內容，歸檔相關的資料，形成工作手冊。技術人員必須對功能模塊、接口等程序代碼進行必要的注釋，形成標準化的技術文檔。一旦發生人員變化，新加入的人員能很快了解項目的基本情況以及之前人員的工作進展。這種情況下，新人能較快適應新工作內容，過渡期能進一步縮短，節省了項目時間。

4.2需求方面：規避策略

項目組制定了需求變更決策機制以及項目需求的確認機制。所有需求變更需通過各部門的接口人提交，在項目組的例會上進行討論。討論內容主要針對需求變更的必要性和緊迫性進行討論。過大的需求變更將會被否決，放在集團客戶業務保障系統二期項目內討論。所有項目需求在確定以后反饋各部門接口人，由接口人負責本部門需求的確認工作。過于主觀的需求不列入需求列表，除非為這些主觀需求設立客觀指標。

4.3施工方面：接受+減輕策略

對于硬件設備到貨延期這一風險事件，項目組采取接受的策略，一方面這類事件發生的概率不是很高，另一方面，系統側重于軟件構架，對于硬件施工來說有比較大的時間余量可以緩沖。項目組為此預留了一定的緩沖時間。

對于施工質量不達標這一風險事件，項目組采取減輕的策略。在施工開始前，項目組向施工人員宣貫機房施工規范；施工時，項目組派人隨工，監督施工質量；施工完成后，項目組及時組織驗收工作，請機房維護人員共同參與驗收，及時發現施工質量問題，給施工整改預留出足夠的時間。

對于施工條件不滿足這一風險事件，項目組也采取減輕的策略。首先將查勘工作做細致，查勘時，派人隨同硬件設計人員以及施工人員一起查勘，查看后及時出硬件安裝方案。查勘結束后盡快安排硬件施工，把從查勘到施工的時間縮到最短，以大幅減少發生機房環境發生變化，不滿足施工條件的概率。

4.4技術方面：轉移策略

本項目中，具體的系統建設工作由專業軟件公司完成，因此技術方面的風險通過合同約定，轉移到了軟件公司，由軟件公司自己把控此類風險。同時，項目組也和軟件公司約定，雖然此類風險由軟件公司承擔，但是如果遇到風險事件，必須及時告知項目組，使項目組對這方面的風險有清楚的了解。

4.5項目管理方面：減輕策略

項目組利用好項目管理工具，提升自身業務水平。在項目規劃過程中，多參考意見的項目案例，多請教相關專家，利用相關方法，盡量減少風險識別遺漏的情況。在與項目干系人溝通的時候，注意溝通方式，保留溝通結果，避免出現誤解的情況。遇到突發事件，多參考以往經驗，多請教相關人員，多溝通，必要時請上級領導出面協調更多資源來解決問題。盡量避免應對不力的情況發生。

4.6外部環境方面：接受策略

在項目風險系數中，外部環境方面的分值較低，出現的概率也較小。而且，其中的這些風險事件是項目組自身較難掌控的。因此，項目組采取接受的策略。以增加時間余量緩沖的方式，應對一些可能發生的情況。

五、總結

本文利用頭腦風暴法，從項目組和相關專家出搜集，整理相關意見，識別出項目風險事件。在風險的定量、定性分析中引入制造業中常用的FMECA方法進行分析，用風險系數來作為風險危害性的評判依據。并創造性的提出將風險的可控性作為風險系數中的一個因素。隨后，本文針對這些風險事件，提出了應對策略。

項目的實際運作表明，項目的風險管理對項目的順利開展起到了很大的幫助作用。本次研究對于上海移動類型項目的建設有很好的指導意義。

參 考 文 獻

[1]項目管理協會，項目管理知識體系指南（PMBOK指南）（第5版），許江林等譯，電子工業出版社，2013

[2]斯帕紐洛，航天項目管理方法與工具，周建平譯，國防工業出版社，2013

[3]梅雪迪恩，曼特爾，項目管理：管理新視角，第七版，戚安邦譯，中國人民大學出版社.2011

[4]沈建明，項目風險管理（第2版），機械工業出版社，2010

[5] R.Max.Wideman， Project and Program Risk Management， Program Management Institute， 1992

[6] Apeland， Aven， Quantifying uncertainty under a predictive epistemic approach to risk analsis， Reliability Engineering and System Safety， 2002