前序
想當年…學了機械專業(yè)，大學畢業(yè)后覺得念工科就是應(yīng)該要實戰(zhàn)一下，不然閉門造車只學理論都不知道在念什么；再來，我也覺得動手比念書有趣多了（OS：其實是不愛念書）。剛進PLM行業(yè)時，聽到實施方法論，是很嗤之以鼻的，尤其當年的實施方法論，比較偏重理論和項目管理層面，對于技術(shù)層面怎么落地并沒有太多著墨。
初次研究實施方法論是在2005年實施某個整車廠PLM項目時，客戶要求所有的交付物產(chǎn)出要符合CMII標準，只好去研究CMII在講什么；到2007年，某個模具廠客戶要求提供詳細的實施方法論和實施模板來證明實施能力，我應(yīng)公司領(lǐng)導的要求匯整了幾年項目實施的經(jīng)驗，并上網(wǎng)研究軟件工程/系統(tǒng)工程方法論，初步編寫了瀑布式方法論對應(yīng)的PLM實施模板（OS：所以先有實務(wù)才映射理論，終于明白理論還是有點道理的）。
圖1. How Projects Really Work
圖1是一張很有名的漫畫，調(diào)侃了交付的IT系統(tǒng)和客戶需求之間因過程控制不力導致的巨大偏差，我從第一次做方案設(shè)計開始就把這張圖貼在桌上警示自己。2008年我轉(zhuǎn)了團隊從臺灣來到上海，擔任PLM團隊的技術(shù)經(jīng)理，按領(lǐng)導的要求圍繞實施服務(wù)質(zhì)量的提升進行變革。我當時一直在思考要怎樣做項目才不會造成上圖的結(jié)果，決定首先要有明確的實施方法論和規(guī)范。我整合了自己以往的項目經(jīng)驗，將2007年做的項目實施模板映射到當時公司實施方法學（VDM）所定義的項目階段，花了幾個月時間完成了針對每個階段的活動內(nèi)容定義以及總計28份技術(shù)文檔模板，這個過程也讓我對于實施方法論有了更深刻的認識。后來，在自己參與主導的某輪胎廠PLM項目中，在各個階段按照活動定義深入應(yīng)用了這些交付件模板，取得了非常好的實施效果（OS：該輪胎廠的PLM實施方案已成行業(yè)標竿，當初要是申請個專利我可能就可以提早退休了）。
在后續(xù)5年中，我在執(zhí)行團隊方案內(nèi)審的過程中，也有意識地強化項目組對交付件模板的應(yīng)用，多個項目的實施結(jié)果也證明了規(guī)范性工作方針及交付件定義確實能提高項目的整體實施質(zhì)量（OS：沒念過碩博，但也審核了清交碩博的項目，心里平衡了?。?。后來公司總部開始重視技術(shù)方面的實施方法，負責此事的團隊來上海進行交流時，更是對此實施交付物模板贊許有加，直言希望能拿去參考交流（OS：并不是國外的月亮就比較圓的）。
圖2. VDM各階段技術(shù)活動和交付件模板清單
2014年，我轉(zhuǎn)換了跑道開始接觸PERFORM實施方法論，結(jié)合軟件平臺的不同特點，我又重新定義了與PERFORM方法論對應(yīng)的本地化技術(shù)文檔模板，并結(jié)合項目的復雜度和實施周期定義了哪些是關(guān)鍵交付件需要客戶簽字（紅色），哪些是輔助文檔（黑色）可根據(jù)項目實際情況靈活裁減。如圖3所示。
圖3. PERFORM各階段交付件模板清單
經(jīng)歷了兩大PLM原廠商的歷練，同時也在網(wǎng)上研究了各家友商提出的實施方法論，我發(fā)現(xiàn)各大廠商或咨詢公司的方法論雖然在命名、階段劃分以及檢查標準方面有所差異，但基本上都遵循著從前往后的瀑布模型原理。雖然也有提出在方案階段就裝好原型系統(tǒng)，讓用戶提前進行了解的，但除此之外似乎也沒有再多能改進優(yōu)化的地方了。
原型方案設(shè)計法
1、緣起
2016年，在轉(zhuǎn)換跑道后我接手的第一個大型項目是某汽車集團技術(shù)中心的PLM實施項目，當時該客戶已經(jīng)花大量時間與金錢進行過咨詢，也有一整套流程改進的文檔。在項目啟動前，客戶方項目經(jīng)理提出了一個挑戰(zhàn)，他說我們有完整的流程體系，也特別挑選了你們比較有經(jīng)驗的實施團隊，那你們能不能不用開展冗長耗時的業(yè)務(wù)調(diào)研（講一堆已經(jīng)知道的東西）而直接開始實施，但又能保障系統(tǒng)對需求的滿足呢？
2、過程
于是，我進行了一個大膽的試驗，提出了原型方案設(shè)計的實施方法。
圖4. 基于原型方案設(shè)計法的工作路線
即在方案設(shè)計階段進行實施方法的調(diào)整：不開展冗長耗時的業(yè)務(wù)調(diào)研，而是在對用戶進行OOTB功能培訓讓用戶對軟件有所初步認知后，由實施方結(jié)合OOTB功能和行業(yè)解決方案，基于實施方顧問的經(jīng)驗，直接給用戶提供詳細到操作界面的方案文檔。然后通過多輪講解和研討，與客戶一起分析數(shù)據(jù)差異以及業(yè)務(wù)需求的滿足程度，反復修改詳細方案以保證其可行性，如圖4所示。在方案審批確認后，后續(xù)項目階段采用瀑布式方式繼續(xù)進行。
原型方案可以采用按功能模塊的方式描述業(yè)務(wù)場景，但必須包括一個整體業(yè)務(wù)流程圖，并在明確定義各功能模塊之間的接口和職責以及整體業(yè)務(wù)流程清晰后，進行分模塊的分工。每個功能模塊的原型方案應(yīng)描述關(guān)鍵業(yè)務(wù)場景和功能說明，并闡明其亮點，如圖5和圖6所示。在描述業(yè)務(wù)場景和功能時，應(yīng)盡可能地展示未來系統(tǒng)的使用界面，以便讓用戶了解未來的操作場景。
圖5. 基于原型方案設(shè)計法的方案編制過程
圖6. 原型方案的模塊分工樣例
原型方案設(shè)計法的優(yōu)點顯而易見：
√ 取消了調(diào)研、簡化了方案講解及審核，降低了項目執(zhí)行過程中對關(guān)鍵業(yè)務(wù)用戶時間的占用。
√ 方案已經(jīng)包含場景步驟并細到系統(tǒng)界面展現(xiàn)，可避免在講解方案的過程中，用戶方與實施方雞同鴨講，因理解不一致而產(chǎn)生偏差。
√ 方案針對真實的實例數(shù)據(jù)進行調(diào)整，可避免在上線后使用的需求偏差。
應(yīng)用
原型方案設(shè)計法適用于兩種情況下的企業(yè)：一是能夠明確定義需求并已了解PLM系統(tǒng)的企業(yè)用戶；二是新興企業(yè)用戶，沒有成熟的業(yè)務(wù)流程和規(guī)范，希望借鑒行業(yè)最佳實踐。這種方法非常依賴于實施方對用戶所在行業(yè)的業(yè)務(wù)流程熟悉程度以及在該行業(yè)中實施PLM項目的經(jīng)驗。
我們已經(jīng)在某汽車集團的的研發(fā)技術(shù)中心PLM項目、某商用車PLM項目、某醫(yī)療科技PLM項目以及某民用航空PLM項目中成功地采用了原型方案設(shè)計法。
敏捷聚焦迭代法
1、緣起
在實施一家合資車企PLM項目時，合資的外方分享他們的實施經(jīng)驗，非常自豪地說使用了Agile方法，卻又說各業(yè)務(wù)板塊的實施負責人自己做自己的，導致系統(tǒng)在數(shù)據(jù)模型方面一團亂，數(shù)據(jù)流也不順暢（OS：這不是顯而易見的結(jié)果嗎？）。不過外方的實施經(jīng)驗仍有可以學習的地方，比如寫用例場景的方式等等。
后來，我有機會去了解某新能源車廠的PLM實施。客戶非常強調(diào)使用者體驗為最高優(yōu)先。但是深入了解后我也看到了一些不太理想的情況：比如沒有事先規(guī)劃整體場景藍圖，想到什么需求就開發(fā)什么需求，相同的數(shù)據(jù)管理場景可以因為不同的車型項目而不一致；過份強調(diào)使用者易用而定義的一系列自動化操作，在真的需要人為交互時反而更麻煩；過份強調(diào)使用者友善性，導致多個系統(tǒng)間反覆交互，影響性能及數(shù)據(jù)正確性；每個迭代周期太短，時間都用在功能代碼開發(fā)和測試上，沒有更新整體場景和整體系統(tǒng)邏輯，最終沒人說得清楚當前系統(tǒng)里哪些開發(fā)是有效的，以及用戶最新使用場景是怎樣的等等。由于上述這些因素，整個敏捷實施變成了一個不斷打補丁、疊床架屋的過程（OS：互聯(lián)網(wǎng)造車，不表示互聯(lián)網(wǎng)思維可以原樣照搬到工業(yè)軟件的實施呀！）。
2、過程
最近我有機會開始負責某新能源車企的PLM實施，客戶要求采用敏捷迭代法實施，我思考良久，要怎么才能規(guī)避之前看到的兩個敏捷迭代實施項目的問題？（OS：終于有機會應(yīng)用并改進敏捷式實施）。
采取以下作法：
先對整個PLM系統(tǒng)進行整體業(yè)務(wù)場景藍圖設(shè)計，然后根據(jù)優(yōu)先級排序劃分每個迭代需要實現(xiàn)的業(yè)務(wù)板塊，接著細化每個業(yè)務(wù)板塊的功能需求，再進行優(yōu)先級排序。最終，得到該迭代需要實現(xiàn)的詳細業(yè)務(wù)場景與功能清單，并使用敏捷開發(fā)進行系統(tǒng)落地和實現(xiàn)，如圖7所示。
在每個迭代結(jié)束后、下一個迭代開始之前，重新審視PLM系統(tǒng)的整體業(yè)務(wù)場景是否需要調(diào)整或更新，再根據(jù)業(yè)務(wù)優(yōu)先排序確定下一個迭代需要實現(xiàn)的業(yè)務(wù)板塊和功能清單。這個過程需要不斷循環(huán)迭代。敏捷聚焦迭代法中“聚焦”一詞的核心要義，就是指迭代的劃分和實施必須基于統(tǒng)一的整體方案及數(shù)據(jù)架構(gòu)，每一次迭代的實施結(jié)果又作為輸入來審視整體方案和數(shù)據(jù)架構(gòu)是否需要調(diào)整和優(yōu)化，兩者互為因果、循環(huán)往復，螺旋式上升。每一次迭代后的審視讓方案和架構(gòu)愈發(fā)完善，而每一次方案的優(yōu)化又可以更好地指導下一個迭代的實施。不同輪次的迭代方案之間相互融合，互為補充。
圖7. 總體業(yè)務(wù)場景圖和拆分迭代實施樣例
為了減少編寫交付物的時間，方案可用Word、PowerPoint甚至AVI形式等靈活展示，只要能解釋清楚場景用例即可，如圖8所示例。
圖8. 場景用例樣例
系統(tǒng)相關(guān)配置部署，可以簡單地用Excel表格記錄，但是必須跟生產(chǎn)系統(tǒng)保持一致。
方案、開發(fā)規(guī)格邏輯及用戶操作場景在多次迭代的過程合并成一份文檔，可同時看到方案、開發(fā)規(guī)格邏輯及用戶操作場景，而且清楚地記錄了變化過程，并讓最新版本始終和生產(chǎn)系統(tǒng)保持一致。比如一個數(shù)據(jù)發(fā)布流程有許多檢查項，在多輪迭代中因為需求變化，可能刪除了一些檢查點、可能增加了一些檢查點，而這些檢查點之間又存在耦合關(guān)系，如果沒有做好場景及規(guī)格記錄，或是僅單獨記錄每個迭代做的事情，可能到最后沒人說得清楚到底在整個數(shù)據(jù)發(fā)布過程中系統(tǒng)檢查了哪些點。
截止目前為止，參照這種做法我們已經(jīng)順利完成了幾輪迭代開發(fā)，配置及功能邏輯規(guī)格清楚，用戶場景也保持在最新的狀態(tài)。系統(tǒng)運行、用戶使用及運維支持均沒有大問題。
依照事先構(gòu)想的改進措施，切身經(jīng)歷此項目后，我感覺在未來的項目里還有很大的改善空間，比如可以仿照之前瀑布式整理一套適合于敏捷聚焦迭代法的規(guī)范性工作方針及交付件模板定義，讓此種實施方式可以更加易于復制和執(zhí)行。（OS：永遠是下一個會更好）。
3、應(yīng)用
敏捷聚焦迭代法適用于兩種情況的企業(yè)：一是基于成熟行業(yè)業(yè)務(wù)流程的新興行業(yè)，比如新能源汽車；二是非傳統(tǒng)制造業(yè)企業(yè)，沒有成熟行業(yè)解決方案可以參照，比如基礎(chǔ)設(shè)施行業(yè)。這種方法非常依賴于實施方的總方案顧問對系統(tǒng)的全面性和系統(tǒng)化的把控程度（OS：可以順便看看如何煉就優(yōu)秀的PLM方案顧問）。
結(jié)束語
雖然理論是必備的，但因地制宜將其靈活地應(yīng)用到實際項目中更為關(guān)鍵。因此，在實施PLM項目時，選擇一個合適的實施方法論和一支能將該實施方法論靈活運用并加以完善的實施團隊是確保項目成功的關(guān)鍵。
達索系統(tǒng) C&SI 合作伙伴
達索系統(tǒng)開發(fā)合作伙伴
