前言
項目實施方法是每個PLM項目實施之初項目團隊需要考慮的問題。傳統的“瀑布式”實施方法是很多實施團隊的首選。該方法將整個項目階段分為需求分析、方案設計、系統設計、系統開發、系統測試、系統上線、用戶培訓等階段，每一階段完成一定任務，交付若干規定的交付物，直至交付最終系統。對于一些全新開發的系統項目，因為沒有現成系統可供客戶參考，因此多采用傳統開發方法。從分析客戶需求開始，經過系統設計和開發，最后交付客戶測試。
但對于一些配置化和商業化程度較高的PLM系統，如ENOVIA，系統本身就包含了一套行業實踐。系統實施的過程的焦點主要集中在應用系統標準功能，同時針對客戶企業的實際流程輔助一些額外功能的客制。對于這種情況，項目團隊可考慮原型法進行實施，以提高項目成功率。
一、傳統PLM實施方法討論
傳統實施方法是一個典型的串行模式。項目啟動后，項目團隊展開需求調研，分析客戶需求。根據分析結果撰寫需求分析報告，作為后續方案設計的依據。需求分析結束后，負責方案設計的顧問根據需求分析報告設計系統方案，期間客戶會展開一定討論；方案定稿后，系統設計工程師和開發工程師展開系統開發和單元測試。系統各單元功能開發完畢后，項目團隊組織客戶進行系統集成測試，完成測試報告。最后組織系統上線。整個實施過程如圖1所示。
圖1 傳統實施過程
實施方法的優勢在于，整個實施過程簡潔明了，環環相扣，節點分明。便于客戶理解。并且各節點任務分明，項目范圍容易界定。
從項目合同執行方面看，這種實施方法也有利于合同的執行。因為各階段任務和交付物定義都比較明確，合同雙方很容易就系統交付和合同款支付方面達成共識。實際上，很多實際項目合同中都有明確規定到什么階段乙方交付哪些交付物，甲方支付多少合同款的條款。
然而，這種實施方法也存在明顯缺點。在需求分析和方案設計階段，客戶并沒有接觸到實際的系統，對未來系統的場景都是通過個人想象，因此每個人的理解都是不一致的；對于系統方案，也多是停留在紙面上，客戶這時并不能理解到這些方案以后在系統中到底是如何實現的，只能選擇信任實施團隊；實施團隊則希望系統開發完成后，客戶參與系統測試時能夠理解和接受方案和最終系統。這樣做的結果是將風險推到了系統測試階段。
在最好的情況下，客戶在測試系統時發現系統實現的正是當初自己設想的，于是順利的完成系統上線和驗收。然而這種情況很少發生。原因如下：
1)在整個項目實施中，客戶除了在需求分析和方案設計階段有參與外，中間其他階段（系統設計，系統開發，單元測試）參與的機會則很少，客戶并沒有太多的機會接觸實際系統。在最終參與測試前，客戶對系統的認識更多的停留在自己的想象或PPT演示中。在這種情況下，如何能保證最終系統與客戶頭腦中設想的系統正好一致呢？
2)在需求分析和方案設計階段，實施團隊與客戶的討論是脫離實際系統進行的。實施團隊了解系統卻不了解客戶的實際業務過程；客戶了解自己的業務過程卻不了解系統；在這種情況下，雙方缺乏一個共同切入點。因此在討論和溝通過程中使用的語言和術語很可能理解不一致，最終導致雙方對形成的“共識”實際上理解并不相同。
以上原因可能最終導致客戶發現測試的系統與當初自己設想的系統不相符。這時，系統開發已經完成，而客戶則反饋系統并不是他們想要的。這對于項目實施團隊來說無疑是一場災難，但又是順理成章發生的結果。
二、快速原型法探討
之所以會發生以上的結果，是因為客戶前期參與時接觸不到實際系統，因此陷入“空對空”的討論；中期又缺乏參與，無法對系統進行深入了解；后期參與時才發現實際與設想大相徑庭。所有的風險被一路后推，最終導致項目陷入僵局。
打破這種僵局，我認為需要讓客戶自始至終中都參與進來，對系統進行評價和反饋。快速原型法可以滿足這一要求。
快速原型法即在系統開發之初，盡快給客戶構建一套系統模型（原型），然后反復演示原型并征求客戶意見，開發人員根據用戶意見不斷修改完善原型，直到基本滿足客戶要求的一種系統實現方法。
對于一些配置化和商業化程度較高的PLM系統， 系統本身就包含了一套行業實踐，即OOTB（Out Of The Box)功能。這些功能基本可以滿足企業的一般業務需求。實施團隊可以以系統標準功能為基礎，對客戶進行系統基礎培訓。然后分析客戶的特殊需求，開展多輪迭代開發。
在項目啟動后，實施方首先對客戶核心用戶進行系統標準功能培訓，使客戶對系統有基本了解。在此基礎上，實施團隊與客戶展開需求分析。實際上，由于客戶對系統已經有了了解，需求分析過程基本也就完成了方案設計。
實施團隊將客戶需求根據重要性進行優先度排序。先將客戶最關注的若干功能在系統中進行配置或開發，交給客戶進行測試，并根據客戶的反饋意見進行調整和修改，直至客戶測試通過；然后實施次關注的功能，如此進行迭代開發。最終結果是客戶的所有需求都在系統中得到實現，并通過客戶測試。如圖2。
圖2 快速原型法實施過程
這種方法使客戶全程參與到項目中。在需求分析之前，客戶核心用戶已經接受系統標準功能培訓，對系統有了基本了解，因此避免了需求分析階段的“空對空”模式，使需求分析更能反映客戶的實際愿望；
在系統設計和開發階段，客戶也并沒有被排除在外。傳統方式是將系統所有功能開發完成后，客戶才參與進來。這樣帶來的風險是，如果開發的功能與客戶設想的功能不一致，不能及時進行調整。這里通過將客戶的需求分步分階段進行開發，使客戶可以及時進行測試，開發人員及時進行調整，從而實現系統功能與客戶期望差異最小化；
以上的結果是系統實施的風險在需求分析和系統開發階段即得到控制，從而增大了風險管控的力度，提高項目的成功率；
從客戶培訓方面看，這種方法使客戶能夠得到最充分的培訓。因為客戶在項目伊始就接受了系統基本培訓，在項目過程中又參與測試，親自操作系統。因此在系統最終交付時，參與的客戶應該對系統掌握會比較深入，甚至可能可以解決一下系統常見問題，為后續系統維護奠定良好基礎。實施團隊也不需要另外單獨花時間對核心用戶進行培訓。
但是，這種方法并非沒有缺點。由于系統實施過程中，客戶的需求是分步分階段逐步實現的，并且每一次迭代都需要通過客戶的測試。這就有可能發生客戶需求不斷蔓延，實施團隊發現客戶需求永遠也得不到滿足，系統交付遙遙無期；
同時，系統開發和測試不像傳統實施方法那樣有明確邊界，給項目合同執行帶來一定模糊性。為合同執行和付款帶來一定的障礙。
針對以上問題，我認為需要從以下方面進行控制：
(1)項目經理需要有較強的項目范圍把握能力。項目實施中應始終圍繞項目目標和方案，抓住客戶主要需求。對于客戶提出的超出項目范圍的需求，需要與客戶進行充分溝通，做好解釋工作；
(2)簽訂合同時雙方應就合同執行階段里程碑做好明確規定，以便后續合同的順利執行；
(3)客戶方應授予核心用戶充足的時間資源，保證核心用戶能全程及時參與。同事核心用戶應具有一定的決策權，以便對每一階段功能測試是否通過做出決定。
三、總結
PLM項目實施中采用的實施方法對項目的成敗起著關鍵性的作用。無論是傳統的實施方法，還是快速原型法，最終的目的都是保證項目實施成功，雙方合作愉快。然而這兩種方法也各有優劣，傳統實施方法過程清晰，階段分明。實施團隊容易把握項目實施范圍，但是卻將項目風險推到了項目后期，不利于項目的風險控制。快速原型法可以使客戶全程參與項目，將項目風險點提前，有利于風險控制，但卻容易用戶需求蔓延，不利于項目范圍控制。在實際項目中，實施團隊需要在項目之初根據實際情況選擇一種最佳的的實施方法，以保證項目順利實施。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文網址：http://www.guhuozai8.cn/html/solutions/14019311360.html
相關文章
