四個階段全面分析PLM項目的風險管理

申請免費試用、咨詢電話：400-8352-114

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

在研究失敗項目產(chǎn)生的原因時，可以從項目集成管理，計劃管理，成本管理，質(zhì)量管理等項目管理的九大管理領(lǐng)域去著手分析。在這其中有一個非常重要的方面就是風險管理。它包括：風險識別、風險分析、風險規(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項目的管理者乃至項目的高層決策者，需要經(jīng)常捫心自問：PLM項目風險管理，我們做得了到嗎？

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

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

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

1. 項目組織

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

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

2. 項目實施范圍與預算

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

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

3. 資源

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

4. 產(chǎn)品和技術(shù)

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