作者：王毅

單位：深圳市精智管理諮詢有限公司

隨著國內企業的發展壯大，近十幾年PLM領域進入爆發期，上PLM系統已成為所有中小型企業的必選項，但大部分企業對上完PLM系統後的效果都不甚理想，基於個人從業經歷，筆者總結主要有以下原因：

高層對PLM缺少正確認知

目前，國內大多數中小型企業中高層管理者對PLM系統的應用經驗較少，甚至是空白，繁雜的日常工作也使其沒有時間精力深入瞭解，只通過顧問公司或者軟體銷售公司的介紹，難以真正理解PLM系統對企業的真正價值，這就造成了“為上系統而上系統”的局面；近些年倡導的 “一把手”工程也誤導了很多企業對於PLM實施的認知，認為只要老闆掛帥，事情至少成功了一半，“一把手”工程確實可以幫助PLM系統進入企業，但是企業能否用好PLM系統，使其起到固化流程、最佳化標準化，提高設計效率，降低研發成本的作用，就不僅僅是“一把手”的事情了。

企業缺少架構系統能力

部分公司高層認為，花了大價錢購買軟體，聘請顧問，就萬事大吉，剩下的工作都是顧問公司的事情；甚至有些企業領導把上系統和買裝置看成一回事，只要購買回來，下面人按照要求操作就能產生應有價值，結果可想而知。根本原因在於公司高層對PLM系統匯入後所帶來的業務變化缺少清晰認知，企業自身沒有架構系統的能力，而顧問公司經驗和水平良莠不齊，實施時受限於顧問本身的行業經驗和經歷，實施效果往往不甚理想，系統上線後問題多、效果差，導致上線後起不到應有效果，投資回報率較低。

企業自身基礎差

企業上PLM系統，需要做一些基本功課，比如最基礎的標準化，從文件模板到設計模板，公司統一的標準件庫，最基礎的文件編碼規則和物料分類及編碼規則等，沒有這些最基本的規則，專案實施風險會成倍增加；

基於上訴原因，對於中小型企業，建議使用基於未來業務場景的方法匯入PLM系統，具體總結如下：

1

PLM軟體系統的選擇

PLM系統匯入企業的第一個難題是選擇哪家的系統？市面上現有PLM產品眾多，讓人眼花繚亂，企業有基於價格選擇的、有基於名氣選擇的、也有基於行業經驗的、更有甚者基於高層喜好選擇的，這些選擇方式不能說錯，但如果不考慮企業現狀，脫離了企業特點，上就不是很靠譜的選擇方式。在此，建議企業可從PLM系統最大資料來源選擇最為匹配的PLM系統，PLM系統歸根到底是管理資料，如果PLM系統沒有資料或者資料準確度太低，那麼上PLM系統沒有任何價值。

如果企業是應上游客戶要求而實施PLM系統，並且要求資料對接，那麼應該選擇和上游企業一樣的PLM產品。

如果公司基於業務發展，需要給研發部門上PLM系統，那麼最大的資料來源頭是研發部門，建議選擇與設計工具是同一家的PLM系統，目前主流的3D設計軟體都有自己的PLM/PDM系統，這樣匹配度最高，實施時出問題的機率也最低。

如果只想單純文件流程管理，可以從易用性、資料安全性的角度出發，選擇本地的PLM系統或者雲系統。

2實施顧問公司的選擇

PLM軟體選型完畢後，就需要選擇合適的PLM實施公司，建議企業選擇專案實施經驗豐富的供應商，並選擇側重於落地經驗豐富而非售前經驗豐富的專案顧問做售前調研，出具詳細的實施方案，把重點關注領域的詳細業務場景（基於未來PLM系統的業務場景）描述清楚，並適當參考最基層員工的建議。

目前，國內大部分售前階段都是銷售與高層在談，基本不涉及到具體的業務場景，這種方式往往容易造成後期專案實施成果和預期差異較大，雙方都不滿意；因此，筆者建議從未來PLM系統匯入後的業務場景出發，把藍圖階段或者詳細設計階段的部分內容提前到售前階段，以減少後期專案實施失敗的風險。

3

專案需明確需求，提出具體實施目標

選擇合適的供應商後，在合同階段，除了價格部分，也需要在專案合同中明確具體的專案目標，不建議以不可考量的專案目標：比如提高設計效率多少百分點或者降低成本多少等，這種目標很難統計，並且也會對專案驗收造成障礙；建議結合企業的實際現狀和問題，基於未來PLM匯入以後的業務場景，提出具體目標。

比如：設計資料的版本管理（解決檔案版本混亂導致的報廢問題），設計資料的唯一資料來源管理（解決多資料來源造成的採購或加工問題），設計資料的電子審批（解決紙質文件的人工受控成本）、歷史資料整理匯入的範圍和方法（解決歷史資料的匯入PLM系統問題）、基於PLM系統變更管理（非文件變更，產品變更問題收集，解決、通知等）、需要實現專案管理（資源管理、專案進度統計等）

根據企業現有業務痛點，有針對性的提出具體的實施目標，這個過程越具體企業的需求就越明確，這不僅有利於顧問的後期服務，也有利於企業對自身需求有一個的清晰思考，決策層和實施層在專案實施前的頭腦風暴和深度思考，能夠為專案成功上線發揮實際作用並提供堅實的基礎。

4

現在與未來具體業務場景對比演示

目前，PLM售前階段的系統實施或者方案，一般都在談戰略、規劃、看起來很高大上實際上方案內容一般都是行業通用解決方案，並不涉及專案上線後結合企業現狀的具體實施結果或效果。但PLM是一個直接面向研發、設計、專案管理等人員的系統，基礎層使用者一般都具有較高的學歷或企業經驗，系統上線後也與他們的本職工作息息相關。如果上線後的效果不好，操作繁複，流程冗餘，即使管理層強行推廣，基礎操作層使用者也會以種種理由（如系統慢、宕機、流程審批時間長等）阻礙系統推廣和日常運營，久而久之就會不了了之，並且運營時間越長，PLM系統問題積攢也越多，口碑也會越差。

筆者建議在專案實施過程中，詳細設計完成後，增加現在與未來具體業務場景對比演示環節。這需要業務顧問對基礎使用者進行詳細的應用培訓，明確PLM系統介入後，對基礎使用者的日常工作會帶來哪些變化。這樣，基礎使用者層在PLM系統正式上線前即可參與進去，有利於減少上線後的各種問題和抱怨。

5

重視底層資料、細節與簡易性，相關全員參與

管理層往往過於重視企業發展戰略、主流程等本身工作相關領域，而對PLM系統落地最關鍵的基礎資料收集、整理、錄入等細節重視力度不夠甚至完全忽略。同時，管理高層對基礎資料產生過程、特點、複雜程度沒有深入瞭解，各部門主要領導基本不深入參與專案實施（大部分只參與調研）、實際產生資料人員對專案沒有發言權。

換句話而言，PLM系統實施往往過於滿足高層需求而忽視基礎使用者層的需求。一般企業在實施PLM系統時，特別在系統架構階段，底層使用者沒有任何決策權，管理高層決策80%的系統架構，但在基礎資料方面，底層使用者提供90%以上的基礎資料；如果底層資料質量太差，PLM系統架構再合理，報表再完美，都是沒有意義的。

萬丈高樓平地起，沒有一個堅實的基礎，公司的戰略和流程無論規劃的多麼合理高效都是水中望月、空中樓閣；沒有完整、準確、高質量的資料作為基礎，任何的規劃都是無意義的。筆者建議在專案落地階段，就把主要精力放在基礎資料以及歷史資料的收集整理中，系統涉及的相關人員需全員參與，公司也需要在政策和獎勵上給予適當支援，這些無形資產都是公司的財富。

一切魔鬼都在細節中，專案的實施過程，具體到每個欄位、每條細枝流程都需要系統實際操作人員的確認與認可，符合資料本身的特點。如果資料錄入過程本身過於繁複，就需要進行改進或二次開發，提高資料進出系統的效率；如果資料本身容易產生問題，就需要進行防呆、防錯、標準化、交叉檢查等手段，基礎資料的完整、準確程度決定未來整個系統的質量程度。

一個成功的系統，無論是最基礎的資料產生還是中間過程的流程審批、資料的二次利用以及最後的歸納報表，在實施過程中都需要全體系統相關人員的親自參與，這樣系統正式上線執行之後才能做到預期規劃和目標相匹配。

6

明確PLM系統資料中心位置，建立唯一資料來源

PLM系統上線且過渡階段完畢後，企業需要下決心從流程和制度上，將線下作業完全取消。一些企業因為種種原因，PLM系統與系統外作業同時存在，這樣就會造成資料來源不唯一，系統執行一段時間後，就會暴露種種問題，例如：

a）為了簡化流程或者加急而設定的一些線下通道被無限制使用；

b）PLM系統資料的不標準、不完整；

c）無有效版本管理。

筆者認為，保持PLM系統資料中心位置至關重要、唯一資料來源的作用也很重要，所以企業一定要下決心取消線下的受控盤、共享盤、個人資料儲存、郵件等資料的儲存和分享方式，確立PLM系統的資料中心位置，建立準確可靠的唯一資料來源。

7

重視持續最佳化

一個成功且優秀的PLM系統，並非由顧問公司實施出來，而是企業本身經過長期運維最佳化的結果。實施公司只能幫助企業建立標準、規範作業、匯入系統，而一個系統是否有用且好用，就需要企業本身長期持續的投入、維護、最佳化。

如果只是靠上線時系統本身的架構和功能，也許可以維持一段時間，但隨著企業本身業務及環境的發展和變化，系統本身又缺少運維最佳化，那麼最終的結果就是越用越不好用，抱怨和障礙增多，勢必會影響PLM系統的正常執行，所以企業在此方面需要長期投入培養相關的人員，最終將系統變成企業資訊化系統不可分割的一部分。

寫在最後

實施PLM系統還有很多其他注意事項，例如：企業的標準化、歷史資料的整理方案、主伺服器硬體架構及網路架構，涉及多個地域的還要考慮異地資料設計協同，異地檔案伺服器管理，與ERP/MES/OA等系統的整合等多個方面。

如果企業本身的資訊化基礎比較差、企業本身又缺少相關人才儲備，管理層對系統功能和特點不熟悉，筆者建議公司內部新增專職的專案經理和系統管理員，專案實施可以考慮小步快跑、分步實施，不要追求大而全的系統，優先選擇有業務痛點的部分，系統上線後能夠起到立竿見影的效果；以點到面逐步實施，既可以節省投入成本，也可以透過此過程讓企業逐漸享受PLM系統上線後所帶來的價值，同時也讓企業內部人員逐漸熟悉系統和相關業務，為後續專案的實施提供堅實的基礎。（完）