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