您的位置:軟件測試 > 軟件項目管理 > 風險管理 >
產品生命周期管理項目風險管理
作者:網絡轉載 發(fā)布時間:[ 2013/5/23 13:52:05 ] 推薦標簽:

品生命周期管理(Product Lifecycle Management-PLM)系統(tǒng)已經在國內多家企業(yè)實施推廣應用。其中既不乏系統(tǒng)推廣效果顯著,為企業(yè)發(fā)展直接助力的成功案例;更不乏項目實施過程跌宕起伏,項目超支或嚴重拖期的案例;還有項目過程轟轟烈烈,結果卻無人問津,企業(yè)的巨額投入化為烏有的例子。成功的項目總是相似,失敗的項目有各自的失敗原因。盡管失敗的原因各不相同,我們如果對這些項目進行由表及里的分析和總結,仍可以從中總結出在未來PLM項目實施過程中需要規(guī)避的風險和問題。倘如此,這些失敗的項目仍不乏其積極的意義。否則是“后人哀之而不鑒之,亦使后人而復哀后人”, 喪失了這些項目帶給我們的借鑒價值。

在研究失敗項目產生的原因時,可以從項目集成管理,計劃管理,成本管理,質量管理等項目管理的九大管理領域去著手分析。在這其中有一個非常重要的方面是風險管理。它包括:風險識別、風險分析、風險規(guī)劃、風險應對策略等若干步驟。英文所述“We don’t go mountain climbing with a rope because we plan to fall, but we’d be all too grateful for the rope if we did.”正可以用來說明項目風險管理的重要性。作為PLM項目的管理者乃至項目的高層決策者,需要經常捫心自問:PLM項目風險管理,我們做得了到嗎?

PLM 項目風險管理的重點不在于事后亡羊補牢的被動應對(當然接受風險帶來的結果也是風險管理的對策之一),而在于在項目執(zhí)行的整個過程中,始終能對潛在的風險進行有效的掌握與控制:時刻關注風險的識別、分析、計劃、記錄、應對、乃至對所有能預見到風險的管理與跟蹤等。其核心在于“Getting IT Before IT Gets You”(用現在時尚的話是:我們要把它搞定,而不是它把我們搞定)。這意味著在進行PLM項目時,也需要從項目生命周期的啟動,規(guī)劃,執(zhí)行與控制,結案等階段來安排項目的風險管理活動。本文也將從上述諸階段來討論PLM項目的風險管理工作。

PLM項目啟動階段-“不謀全局者,不足謀一域”

在PLM項目啟動前,一個值得項目經理和項目高層重點關注的問題是:決定項目成敗的諸多因素,我們考慮周詳了嗎?而對這些因素的識別,其實是項目管理過程中風險識別的過程。在這一過程中,通常可以從如下方面去對風險因素加以歸類梳理:

1. 項目組織

PLM 系統(tǒng)的實施,其實質是企業(yè)業(yè)務變革與組織變革過程的一部分,因此識別企業(yè)業(yè)務變革與組織變革過程中會遇到的問題并加以處理,成了PLM項目風險管理重要的一部分內容。盡管所有的人都希望看到PLM項目“上下同欲”的結果,但由于PLM系統(tǒng)的推廣與部署會涉及到企業(yè)業(yè)務的多個方面,不同干系人(stakeholder)的利益不盡相同,其在企業(yè)實際業(yè)務過程中關注的焦點也不盡相同,因此在項目執(zhí)行過程中往往容易受到各種組織或人事因素的影響。當這種因素處置不當時,某些風險因素會逐步變成影響項目正常執(zhí)行的問題。因此在項目啟動之初建立起一套經項目高層決策者批準的高效運做的項目組織架構及附屬的正常運做流程成了決定項目能否成功的一個重要方面。曾幾何時,PLM項目組在為所提交的方案沒有人簽字確認而苦惱時;在為決定項目成敗的數據準備工作停滯不前而絞盡腦汁時;在為用戶接受測試(UAT)的測試人員似走馬燈般難以固定而憂心忡忡時,其實首先應該想到的是:是否是PLM項目控制機制(Governance Model)及組織架構出了問題。項目組織帶來的問題不僅會影響到項目組顧問方與客戶方彼此之間的工作效率,在顧問方內部或客戶方內部也容易出現政出多頭,前后不一的問題。當這種情況發(fā)生時,通常會極大損害項目運作的效率,導致項目工期的拖期或成本的嚴重超支。

在規(guī)避項目組織先天不足對PLM項目帶來的危害時,特別需要得到企業(yè)高層領導的切實有效的支持,從而建立起高效運作的PLM項目管理體系,在有些情況下甚至可以借鑒 “威權政治”的做法。惟有如此,才可以為PLM啟動后項目的運作奠定堅實的基礎。

2. 項目實施范圍與預算

項目范圍,預算和時間是制約項目執(zhí)行的三個關鍵要素。當任何一種要素發(fā)生變化時,都會導致其它兩個要素的變化。這是一個人所共知的項目管理常識。但在具體的項目執(zhí)行過程中,卻仍然會經常因為上述三個要素之間的沖突而影響或羈絆項目的正常執(zhí)行。

這意味著,在項目啟動之初需要對項目實施范圍有著全面而又清晰的認識。但要真正做到這一點通常又是一件非常困難的事情。這主要是由于在項目啟動之初在客戶與實施顧問之間存在著PLM產品信息的不對稱性和客戶業(yè)務需求信息的不對稱性。為規(guī)避該風險帶來的問題,在項目實施之初,PLM實施客戶不妨以同行業(yè)其它實施單位的成功案例作為標桿(Benchmark),通過參考與本企業(yè)類似的成功企業(yè)的實施經驗,并比照兩企業(yè)的異同來確定本單位的實際需求范圍;同時可以考慮吸納那些有過類似行業(yè)成功經驗的顧問組成項目團隊(注意是真正有成功與失敗兩方面實施經驗的顧問,而不是某些徒有其表的PLM“感念”專家或簡歷包裝華麗的某些顧問。而甄別其間的差別其實是有章可循的。);此外還需要在項目啟動之初確定客戶與顧問彼此之間業(yè)務需求與PLM知識的知識傳遞計劃(KT Plan)。從而有效保證上述知識不對稱性對項目帶來的致命影響,并基本做到在項目實施之初,客戶與顧問團隊之間能圍繞項目實施的基準范圍(Baseline Scope) 達成初步的一致。

3. 資源

為保證 PLM項目真正成功,需要保證在項目執(zhí)行過程的各個階段,能有恰當的具備特定能力的資源投入,因此在項目啟動之初獲得各方對所需資源進行支持的背書是極為重要的。在以往的項目案例中,作為客戶方通常會在項目執(zhí)行之初會對顧問的能力提出較高的要求,有時還會安排必要的面試或初步篩選。但在項目啟動之初,客戶方項目管理組時常會忽略對己方業(yè)務定義,數據準備,開發(fā)實現,用戶接受測試乃至系統(tǒng)支持等方面資源的需求,從而在上述方面缺少必要的或完備的資源需求計劃。由此帶來的后果,要么是在規(guī)定的時限內,業(yè)務需求的準確定義無法完成;要么是未來系統(tǒng)上線時,關鍵的業(yè)務數據還無法進入到系統(tǒng)中,影響系統(tǒng)的真正切換;要么是項目結束顧問資源撤出后,雙方項目組突然發(fā)現客戶難以獨立承擔系統(tǒng)的調整或問題的處理工作并導致PLM系統(tǒng)推廣部署的難度加大。實際上,在項目啟動之初,項目經理在規(guī)劃項目資源時,應該考慮項目所涉及到的全部所需資源,并為此制訂在整個項目執(zhí)行周期內所需的資源需求計劃。在此基礎上去分析各種可能潛在的資源風險,從而對資源風險進行有效管理和跟蹤。這種資源的規(guī)劃并不意味著在項目啟動之初加以定義萬事大吉,相反,項目經理需要在項目執(zhí)行的各個階段對涉及資源的風險不斷地加以跟蹤和管理,才有可能達到項目預期的目的。

4. 產品和技術

在PLM 項目啟動之初,絕大多數客戶對PLM產品和技術懷有濃厚的興趣——這是天性使然:畢竟所有的客戶都希望采用先進的技術來解決自己所面臨的實際問題。但在關注先進產品和技術的同時,一定要考慮這些產品或技術是否與客戶當前使用的現有產品相匹配,是否與自己的業(yè)務實際相匹配。一個典型的案例是:當客戶引進 PLM產品新版本后,在項目實施的后期(系統(tǒng)實現階段)突然發(fā)現客戶自己的CAD版本無法與當前PLM實施版本相兼容,原來規(guī)劃的所有CAD集成的計劃都變成了泡影;已經發(fā)生的很多人力資源投入產生的結果也化為了烏有;部分項目目標也受到了影響,。與此相類似的另一個案例是,項目實施已經如火如荼地進行到后期階段,客戶方采購的關鍵服務器設備卻始終沒有到位,而終用戶驗證測試是在一臺跟生產服務器迥異的測試服務器上進行的。這一方面導致整個項目的拖期,另外一方面在服務器到貨后,所有的測試、問題修改工作需要在與新的服務器類似的測試環(huán)境中重新測試。于是導致系統(tǒng)交付時間延期和前期資源投入的浪費!因此在強調先進的技術或功能完善的產品時,需要重點考慮企業(yè)的實際IT架構和工具使用情況并在項目啟動之初給出圍繞這些內容的總體評價,從而據此選擇適合企業(yè)IT發(fā)展規(guī)劃的產品與技術。

上一頁123下一頁
軟件測試工具 | 聯(lián)系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網站地圖
滬ICP備07036474 2003-2017 版權所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd