聯想公司專案風險管理解決方案及應用
1 引言
專案是在複雜的自然和社會環境中進行的,受眾多因素的影響。對於這些內外因素,從事專案活動的主體往往認識不足或者沒有足夠的力量加以控制。專案的過程和結果常常出人意料,有時不但未能達到專案主體預期的目的,反而使其蒙受各種各樣的損失;而有時又會給他們帶來很好的機會。專案同其他的經濟活動一樣帶有風險。要避免和減少損失,將危險化為機會,專案主體就必須瞭解和掌握專案風險的來源,性質和發生規律,進而實行有效的管理。
同樣,在聯想消費產品的研製過程中,一直伴隨著多種不確定的風險問題。我們根據消費產品研發的實際情況和風險的特性,並且結合我們已經開發使用的軟體方案中存在的一些遺留問題,詳細規劃,給出一套完整的風險解決方案。
2 風險解決方案
2.1 現狀分析
電腦產品的開發和研製過程自始至終充滿了錯綜複雜的矛盾和大量的不確定性,根據不同的風險特性和業務活動情況,我們將產品研發業務分成產品啟動階段、制定計劃階段、具體實施階段和收尾階段。每個階段的風險大致描述為:
產品啟動階段,對使用者群把握不準確,造成整個產品的設計理念和設計方向與實際的市場需求偏移,或者由於對市場的變化反映遲緩,產品啟動階段發現其它公司的同種或更
制定計劃階段,專案管理人員與專案實施人員之間的溝通不善,或者對專案中出現的風險問題預估不夠,造成專案計劃與實際操作方式偏移;
具體實施階段出現的問題一般比較複雜,包括經濟方面的風險問題、技術方面的風險問題,以及其他的一些不確定的社會或人為的風險問題;
收尾階段仍然存在少量的風險。
所以說,產品研製從啟動、制定計劃、具體實施到收尾的過程中,一直存在著風險的問題,也一直存在著專案中止的可能性。專案的不同階段會有不同的風險。實時監控,迅速瞭解並解決風險問題是保證專案實施的關鍵。
2.2 方案介紹
專案執行的各個階段,均伴隨著風險的評估和處理。所以,如何記錄和處理相應的問題,是我們目前面臨的急需解決的問題。消費電腦事業部針對這個問題,在天麒、天麟產品的研發階段曾經開發過相應的B/S(browse/server)架構的小軟體,將產品研發過程中出現的問題展示在內部平臺上,展示的主要內容包括:出現問題的相關部件、出現問題的時間、解決方式等相應項,供相關的工程師填寫,相應的專案小組成員,專案決策人員查閱,能達到顯示專案中出現的風險問題,以期迅速解決的目的。但是,對軟體的實用情況作了相應的調查後,我們發現工程師認為該軟體並不能全部滿足他們的需求,主要體現在:
沒有對相關問題的風險度的評估。可能有些問題對專案的實施各方面造成的影響微乎其微,也可能某個問題的出現可能導致整個專案的完結時間延遲,造成很大的影響。在該軟體中沒有相關的風險度的評估;
資訊與角色之間的對應關係不明確。工程師關心的是自己的部件方面出現的問題,以及對本部件會產生影響的其他部件出現的問題;專案管理人員可能對某些關鍵部件(計劃中處於關鍵路徑上的部件)的關注程度較高;對於專案決策人員而言,需要的是經過提煉的,對決策有幫助的檔案。但是上述方案中沒有相應的規劃。
部件的問題與專案中的任務之間的關係不明確。部件的研發存在著生命週期,在不同的生命階段,出現的風險是不同的,風險造成的影響也是不同的。這方面的資訊對專案管理人員是非常重要的。
針對以上出現的種種缺憾,我們保持了B/S架構體系,重新對規劃風險問題,以期滿足不同角色的需要,給出瞭如下的風險記錄和解決的設計方案。
首先,確定風險問題的定位。一般而言,一個專案的風險主要體現在專案中的任務是否能如期完成,資源是否能合理使用等問題上。簡而言之,專案風險與專案任務不可分割。所以,我們在軟體中引入WBS(Work Breakdown Structure工作分解結構)字典的概念,為消費產品的研製制定WBS字典,將產品研製過程中的專案可交付成果分成更小的、更容易管理的單元。伴隨著WBS字典的釋出,目前執行相關的專案任務將是WBS字典的一個子集。所以,將專案任務中出現的風險與相關的任務緊密銜接,構成同一個任務的目前出現的所有風險問題的集合,簡稱風險集。如圖1所示。這樣做的另一個好處是所有正在執行或已經結束的專案中出現的風險問題將會存放在相應的WBS單元中。如此,我們在本次專案執行的各階段,不但可以遞交目前的風險問題,還可以查閱以前專案相應單元中出現的風險問題,有利於風險的規避和風險的應對。
其次,不同的風險,對專案所起的作用和影響均不同,所以,應該存在風險的量化問題。目前階段,為便於處理風險問題,我們簡單的給出了一種二維量化標準。用(延期可能性,風險危害程度)這種二維陣列表徵風險問題。其中,延期的可能性指本問題出現的可能性,由工程師填入相應的百分比數字。而風險的危害程度分成高,中,低三部分,分別對應對整個專案造成延期的可能性,對本部分造成延期的可能性和對本次任務造成延期的可能性。當然,由於風險的本身特性和消費產品研製的過程中出現的不確定性因素太多,如何界定當前風險的危害程度,目前還沒有一個數學方案,還依賴有經驗的工程師的決斷。
最後,對不同角色的專案參與人,在專案中所處的地位不同,對風險的認識的方面也有所不同。部件工程師關注的是單個部件的風險問題,專案管理者關注的是造成專案延期的最大可能性的問題,而決策者關注的是風險的可承擔性的問題。如下的風險用例圖即顯示不同角色需要的不同的資訊資料。
工程師發現在部件的研發過程中出現某個問題,可能引起該階段任務的完成時間延遲。工程師必須向專案管理人員提供這種風險問題的後果,造成後果的可能性,以及風險的嚴重性等風險屬性,同時,為便於知識的積累,還應提供相應的解決方案。專案管理人員收到來自工程師的風險評估報告,他首先關心的應該是該部件的運作是否處於關鍵路徑上,對專案整體造成的影響會有多大,對其他部件造成的影響會有多大,能按時解決的可能性將會有多少。與其他的風險問題綜合,定期提交給專案決策人員,使專案決策人員能實時瞭解專案運作中出現的風險問題,有的放矢的制定出決策方案。對於專案決策人員而言,收到的資訊應該是經過專案管理人員提煉之後的資料資訊。知道專案進度正常與否,風險是否在可控範圍內即可。
2.3 方案實現
在方案實施方面,最重要的就是風險量化和定製化介面的概念,將風險問題用不同的符號標識出來,角色與資訊對應起來。使不同的專案角色能對不同的風險問題做出迅速的反映,快速解決專案風險問題。詳細說明如下:工程師頁面中要求錄入的內容與第一版的軟體相比,改動內容不大。但主要是為滿足部件之間的配置管理以及風險量化管理,做出如下補充:可定製顯示其他相關聯部件的風險問題資訊;將專案中出現的問題集與WBS單元結合,選擇相應的專案任務填寫出現的問題;對應每種風險,要求提交相應的風險度,即(延期可能性,風險危害程度)。
專案管理人員需要全面監控和協調專案中出現的不確定性問題,所以,專案目前執行進度和專案中出現的風險問題是專案管理人員必須時刻關注的。以下提供的專案管理人員的進度-風險圖。如圖3所示。在本頁面中,最重要的是風險量化的概念。將風險問題用四種色彩標識出來,其中,紅色表示嚴重的風險問題,需要給予足夠的重視,否則會引起專案重大變更;黃色表示中度風險問題,影響範圍相對小一些;綠色表示風險問題在可控制範圍,造成的影響不大。對各種風險問題,一經解決,改用藍色標識,以示區別。同時,在圖中用進度條標識專案目前執行的階段。將專案進度問題與專案中風險問題銜接起來,專案管理人員可清晰的瞭解目前專案運作狀態,以及專案中出現的問題。
對專案決策人員而言,無需瞭解專案中出現的具體問題,應該關注的是專案實施的正常與否。可提供圖形化的介面,顯示專案的進度以及專案各階段的風險數以及專案風險的評估等級即可。詳細的總體風險評估由專案管理人員提交相應的備註檔案說明。
3 結論
風險管理是聯想消費電腦事業部專案管理的一個重要組成部分。在此提出的風險解決方案是我們結合消費產品研製的現狀和專案組成員的需求制定出來的,實踐證明,該套方案能滿足目前我們對風險管理的需要,可以將一些不確定性問題挖掘出來,量化處理。WBS字典的加入,風險問題和專案任務緊密結合起來,並且能轉化為一種知識和技術積累,使工程師們寶貴的經驗不至於白白流失,為後續的工作提供了良好的指導。
但是,產品研發的過程中出現的問題是多樣的,我們對過程中出現問題的研究還是遠遠不夠的。例如,目前我們研究的風險的等級和發生的可能性還是要依賴工程師的判斷,但是,不同的工程師對不同風險問題的理解不同,給出的數字也是不同的,所以,引入神經網路系統對相應的風險等級和發生的可能性進行判斷,將是我們下一步要研究的問題之一。我們明確,企業中專案風險管理目前還遠遠沒有成熟,需要大家不斷的努力,挖掘新的解決方案,完善專案管理體系。
專案是在複雜的自然和社會環境中進行的,受眾多因素的影響。對於這些內外因素,從事專案活動的主體往往認識不足或者沒有足夠的力量加以控制。專案的過程和結果常常出人意料,有時不但未能達到專案主體預期的目的,反而使其蒙受各種各樣的損失;而有時又會給他們帶來很好的機會。專案同其他的經濟活動一樣帶有風險。要避免和減少損失,將危險化為機會,專案主體就必須瞭解和掌握專案風險的來源,性質和發生規律,進而實行有效的管理。
同樣,在聯想消費產品的研製過程中,一直伴隨著多種不確定的風險問題。我們根據消費產品研發的實際情況和風險的特性,並且結合我們已經開發使用的軟體方案中存在的一些遺留問題,詳細規劃,給出一套完整的風險解決方案。
2 風險解決方案
2.1 現狀分析
電腦產品的開發和研製過程自始至終充滿了錯綜複雜的矛盾和大量的不確定性,根據不同的風險特性和業務活動情況,我們將產品研發業務分成產品啟動階段、制定計劃階段、具體實施階段和收尾階段。每個階段的風險大致描述為:
產品啟動階段,對使用者群把握不準確,造成整個產品的設計理念和設計方向與實際的市場需求偏移,或者由於對市場的變化反映遲緩,產品啟動階段發現其它公司的同種或更
制定計劃階段,專案管理人員與專案實施人員之間的溝通不善,或者對專案中出現的風險問題預估不夠,造成專案計劃與實際操作方式偏移;
具體實施階段出現的問題一般比較複雜,包括經濟方面的風險問題、技術方面的風險問題,以及其他的一些不確定的社會或人為的風險問題;
收尾階段仍然存在少量的風險。
所以說,產品研製從啟動、制定計劃、具體實施到收尾的過程中,一直存在著風險的問題,也一直存在著專案中止的可能性。專案的不同階段會有不同的風險。實時監控,迅速瞭解並解決風險問題是保證專案實施的關鍵。
2.2 方案介紹
專案執行的各個階段,均伴隨著風險的評估和處理。所以,如何記錄和處理相應的問題,是我們目前面臨的急需解決的問題。消費電腦事業部針對這個問題,在天麒、天麟產品的研發階段曾經開發過相應的B/S(browse/server)架構的小軟體,將產品研發過程中出現的問題展示在內部平臺上,展示的主要內容包括:出現問題的相關部件、出現問題的時間、解決方式等相應項,供相關的工程師填寫,相應的專案小組成員,專案決策人員查閱,能達到顯示專案中出現的風險問題,以期迅速解決的目的。但是,對軟體的實用情況作了相應的調查後,我們發現工程師認為該軟體並不能全部滿足他們的需求,主要體現在:
沒有對相關問題的風險度的評估。可能有些問題對專案的實施各方面造成的影響微乎其微,也可能某個問題的出現可能導致整個專案的完結時間延遲,造成很大的影響。在該軟體中沒有相關的風險度的評估;
資訊與角色之間的對應關係不明確。工程師關心的是自己的部件方面出現的問題,以及對本部件會產生影響的其他部件出現的問題;專案管理人員可能對某些關鍵部件(計劃中處於關鍵路徑上的部件)的關注程度較高;對於專案決策人員而言,需要的是經過提煉的,對決策有幫助的檔案。但是上述方案中沒有相應的規劃。
部件的問題與專案中的任務之間的關係不明確。部件的研發存在著生命週期,在不同的生命階段,出現的風險是不同的,風險造成的影響也是不同的。這方面的資訊對專案管理人員是非常重要的。
針對以上出現的種種缺憾,我們保持了B/S架構體系,重新對規劃風險問題,以期滿足不同角色的需要,給出瞭如下的風險記錄和解決的設計方案。
首先,確定風險問題的定位。一般而言,一個專案的風險主要體現在專案中的任務是否能如期完成,資源是否能合理使用等問題上。簡而言之,專案風險與專案任務不可分割。所以,我們在軟體中引入WBS(Work Breakdown Structure工作分解結構)字典的概念,為消費產品的研製制定WBS字典,將產品研製過程中的專案可交付成果分成更小的、更容易管理的單元。伴隨著WBS字典的釋出,目前執行相關的專案任務將是WBS字典的一個子集。所以,將專案任務中出現的風險與相關的任務緊密銜接,構成同一個任務的目前出現的所有風險問題的集合,簡稱風險集。如圖1所示。這樣做的另一個好處是所有正在執行或已經結束的專案中出現的風險問題將會存放在相應的WBS單元中。如此,我們在本次專案執行的各階段,不但可以遞交目前的風險問題,還可以查閱以前專案相應單元中出現的風險問題,有利於風險的規避和風險的應對。
其次,不同的風險,對專案所起的作用和影響均不同,所以,應該存在風險的量化問題。目前階段,為便於處理風險問題,我們簡單的給出了一種二維量化標準。用(延期可能性,風險危害程度)這種二維陣列表徵風險問題。其中,延期的可能性指本問題出現的可能性,由工程師填入相應的百分比數字。而風險的危害程度分成高,中,低三部分,分別對應對整個專案造成延期的可能性,對本部分造成延期的可能性和對本次任務造成延期的可能性。當然,由於風險的本身特性和消費產品研製的過程中出現的不確定性因素太多,如何界定當前風險的危害程度,目前還沒有一個數學方案,還依賴有經驗的工程師的決斷。
最後,對不同角色的專案參與人,在專案中所處的地位不同,對風險的認識的方面也有所不同。部件工程師關注的是單個部件的風險問題,專案管理者關注的是造成專案延期的最大可能性的問題,而決策者關注的是風險的可承擔性的問題。如下的風險用例圖即顯示不同角色需要的不同的資訊資料。
工程師發現在部件的研發過程中出現某個問題,可能引起該階段任務的完成時間延遲。工程師必須向專案管理人員提供這種風險問題的後果,造成後果的可能性,以及風險的嚴重性等風險屬性,同時,為便於知識的積累,還應提供相應的解決方案。專案管理人員收到來自工程師的風險評估報告,他首先關心的應該是該部件的運作是否處於關鍵路徑上,對專案整體造成的影響會有多大,對其他部件造成的影響會有多大,能按時解決的可能性將會有多少。與其他的風險問題綜合,定期提交給專案決策人員,使專案決策人員能實時瞭解專案運作中出現的風險問題,有的放矢的制定出決策方案。對於專案決策人員而言,收到的資訊應該是經過專案管理人員提煉之後的資料資訊。知道專案進度正常與否,風險是否在可控範圍內即可。
2.3 方案實現
在方案實施方面,最重要的就是風險量化和定製化介面的概念,將風險問題用不同的符號標識出來,角色與資訊對應起來。使不同的專案角色能對不同的風險問題做出迅速的反映,快速解決專案風險問題。詳細說明如下:工程師頁面中要求錄入的內容與第一版的軟體相比,改動內容不大。但主要是為滿足部件之間的配置管理以及風險量化管理,做出如下補充:可定製顯示其他相關聯部件的風險問題資訊;將專案中出現的問題集與WBS單元結合,選擇相應的專案任務填寫出現的問題;對應每種風險,要求提交相應的風險度,即(延期可能性,風險危害程度)。
專案管理人員需要全面監控和協調專案中出現的不確定性問題,所以,專案目前執行進度和專案中出現的風險問題是專案管理人員必須時刻關注的。以下提供的專案管理人員的進度-風險圖。如圖3所示。在本頁面中,最重要的是風險量化的概念。將風險問題用四種色彩標識出來,其中,紅色表示嚴重的風險問題,需要給予足夠的重視,否則會引起專案重大變更;黃色表示中度風險問題,影響範圍相對小一些;綠色表示風險問題在可控制範圍,造成的影響不大。對各種風險問題,一經解決,改用藍色標識,以示區別。同時,在圖中用進度條標識專案目前執行的階段。將專案進度問題與專案中風險問題銜接起來,專案管理人員可清晰的瞭解目前專案運作狀態,以及專案中出現的問題。
對專案決策人員而言,無需瞭解專案中出現的具體問題,應該關注的是專案實施的正常與否。可提供圖形化的介面,顯示專案的進度以及專案各階段的風險數以及專案風險的評估等級即可。詳細的總體風險評估由專案管理人員提交相應的備註檔案說明。
3 結論
風險管理是聯想消費電腦事業部專案管理的一個重要組成部分。在此提出的風險解決方案是我們結合消費產品研製的現狀和專案組成員的需求制定出來的,實踐證明,該套方案能滿足目前我們對風險管理的需要,可以將一些不確定性問題挖掘出來,量化處理。WBS字典的加入,風險問題和專案任務緊密結合起來,並且能轉化為一種知識和技術積累,使工程師們寶貴的經驗不至於白白流失,為後續的工作提供了良好的指導。
但是,產品研發的過程中出現的問題是多樣的,我們對過程中出現問題的研究還是遠遠不夠的。例如,目前我們研究的風險的等級和發生的可能性還是要依賴工程師的判斷,但是,不同的工程師對不同風險問題的理解不同,給出的數字也是不同的,所以,引入神經網路系統對相應的風險等級和發生的可能性進行判斷,將是我們下一步要研究的問題之一。我們明確,企業中專案風險管理目前還遠遠沒有成熟,需要大家不斷的努力,挖掘新的解決方案,完善專案管理體系。
相關文章
- PFMEA在專案風險管理中的應用
- 化工企業安全風險管控數字化解決方案
- 資料專案風險-都在為別人著想
- FMEA技術在IT專案風險管理中的應用
- 專案管理之風險管理案例-專案交付風險專案管理
- 達觀專案文件風險智慧分析系統,助力廣西電網實現專案風險管控
- 專案風險管理
- 專案風險管理:透過五步降低風險
- 化工集團公司安全風險智慧化管控平臺
- 如何運用FMEA降低IT專案的技術風險?
- 解決方案:邁道科技危險化學品企業安全風險智慧化管控平臺
- 集團施工企業安全生產管理/風險管控數字化解決方案
- 管控風險的方法
- 如何更有效管理專案風險?
- 區塊鏈溯源落地應用專案上鍊解決方案區塊鏈
- 外包公司專案管理的問題應該怎麼管專案管理
- 什麼是專案風險管理?要如何執行風險管理?
- 電信行業專案管理解決方案(常見挑戰&解決方案)行業專案管理
- AI輔助專案管理過程風險分析與應對AI專案管理
- Serverless 時代下微服務應用全託管解決方案Server微服務
- 應急監管雙重預防機制數字化管理解決方案
- 產品資料管理PDM的專案管理解決方案專案管理
- 離職後,把之前在公司寫的專案開源,有法律風險嗎
- 併發請求導致的業務處理安全風險及解決方案求導
- TL,你是如何管理專案風險的?
- 多專案管理中的難題及解決方案專案管理
- serverless 專案配置及建立helloworld應用(二)Server
- ASP.NET 微軟Web應用示例程式走廊-專案解決方案ASP.NET微軟Web
- 北京“721災難”風險管控分析
- Android應用安全常見問題及解決方案Android
- 研發管理與專案管理:痛點及解決方案專案管理
- ClubSphere專案主要風險和典型使用者
- 物聯網滲透測試威脅建模,捕捉應用相關安全風險
- 儲戶資金刷臉被盜,監管部門發文警示人臉應用風險
- 7種大模型風險及API 管理應對策略大模型API
- 功能設計:專案費用管控
- 管理專案風險:考慮你的專案可能出現的問題
- vue 專案白屏解決方案Vue