談到PDM的實施，很多人微微一笑：PDM跟ERP一樣，同屬于企業信息化的組成部分，企業信息化實施不就是那么幾條么，什么"一把手工程"，什么"整體規劃，分步實施"么。再難，它也就管理那么一點業務，能難到那里去？可是漸漸的，很多企業發現，PDM實施的難度一點不亞于其他信息化系統，但是又說不清楚到底難在什么地方，更談不上找到實施PDM時的突破口。下面談談個人一點粗淺的認識。
首先讓我們看看"一把手工程"。廢話，一把手是企業的最高領導，別說信息化，企業里的事情只要"一把手"發話，沒有辦不好的（當然，除非下面辦事的不想在企業混了）。那么憑什么這句話就成了企業實施信息化的必勝法寶呢？
再讓我們看看"整體規劃，分步實施"。還是廢話，除非哪個企業領導有魄力停工停產，管理體系推倒重來，否則誰都知道 "一口吃不了個胖子"這個地球人都知道的道理，為啥到了實施信息化的時候就成了尚方寶劍呢？
面對上面的問題，我只能悲哀的說：那是因為沒有找到實施方法。當然，這里我不能說我就一定找到了實施的方法，我只想談談我的感想。
首先，"一把手工程"這句話在實施PDM的時候是不起作用的。因為PDM的主要用戶是以金屬加工為主的制造業企業（也包括設計院、研究所），而這類企業的"一把手"往往負責生產，技術則由副總負責，而PDM是技術管理信息化，最直接面對的高層領導就是所謂的技術副總。技術副總在企業往往只能是"三把手"或者"四把手"（"二把手"往往負責財務）。在這種情況下，所謂的"一把手工程"在實施PDM的時候只能是句口號。
其次，"整體規劃，分步實施"在實施PDM的時候同樣不起作用。因為PDM的實施是線性的，不可能像ERP或者其他系統一樣并發。舉個例子來說，所有的企業實施PDM都是從圖文檔管理著手，然后逐步推廣到工作流甚至是項目管理，目前還沒有聽說哪個企業跳過圖文檔直接實施項目管理的。有了這樣的前提自然談不上什么"整體規劃"，因為"分步實施"已經是約定俗成的了。而ERP就不是這樣，企業可以有選擇的上若干個實施周期短、見效快的模塊然后再上其他模塊，這種模塊之間的搭配往往非常靈活。
再次，PDM與ERP等系統一個顯著的差別就是，PDM系統是一個見效緩慢的信息化系統。一方面體現在，只有PDM中的數據量達到一定程度以后，PDM的價值才能顯現。另外一方面，PDM有點類似保險，不出事的時候沒人覺得它重要，一旦出事PDM的某些價值才能閃光，比如最基礎的圖文檔管理。而ERP的"進、銷、存"等模塊幾乎是一上就有效果，因為它促使企業把許多年都盤不清的庫存盤清楚了。
最后，PDM的主要應用群體集中在企業的技術部門，我國幾乎所有的制造業企業的領導都承認（外國暫時還沒了解），技術人員在企業是最不好管理的一個群體，打打不得，罵罵不得。面對這樣一群企業里面的大爺，企業自己的領導都束手無策，PDM廠商這些外來的和尚的經自然就不是那么好念了。
那PDM究竟要怎樣實施呢？如何才能實施好PDM呢？
按照系統的大小和難度，PDM目前主要有兩種實施方式。一種是以Teamcenter和Windchill為代表的先培訓，再實施的方式；一種是國內廠商為代表的邊培訓邊實施的方式。
具體來說，Teamcenter和Windchill在實施開始階段會對項目實施小組進行培訓，讓他們了解整套系統，然后讓各業務部門組織討論，提出具體的需求。根據這些需求，軟件廠商再編制解決方案，當然，這個解決方案是比較偏技術層面的。當解決方案獲得雙方認可后組織相應的開發和實施。然后再培訓，再開發。如此往復，項目進展呈現一個螺旋上升的狀態。而國內廠商一般都是先進行需求調研，然后進行配置開發，然后培訓推廣，然后結項。在實施開始的階段，企業對PDM的認識和了解完全來自銷售人員的演示。
現在無法評述兩種方式的好壞，國外軟件的實施方式比較適合大型系統，企業投入大，項目周期長。國內軟件的實施方式比較適合小型系統，項目周期短，回款快。不過兩種方式都強調了培訓，可見培訓在PDM實施過程中的重要性。為什么培訓如此重要？個人認為一個詞就可以解釋：參與感。
其實任何信息化系統的實施都面臨一個這個很現實的問題。我常常聽見實施人員抱怨："技術人員就是不用，我能有什么辦法呢。"這就是企業的終端用戶參與感不夠的集中表現。沒有足夠的參與感，用戶就無法認同你的工作乃至整個PDM系統。在走訪了一些實施不好的企業發現，往往實施人員忙的昏天黑地，技術人員或者技術部門的負責人還不知道這個系統是干什么的，為什么要上。直到最終按照技術要求驗收了，整個系統還是沒有得到應用。
記得我實施的第一個項目是接上個項目經理的爛攤子，按照功能基本都滿足了，但是技術部門一個客戶端都還沒有安裝。用戶非常惱火，第一次見面直接就跟我說："現在我們談談如何終止這次合作吧。"在實施重新啟動后，我做的第一件事就是讓用戶從技術部門抽調2個人配合實施。我花了三天時間，從PDM的原理到我們PDM產品功能全面給他們進行了培訓。然后又手把手教他們配置和二次開發，隨后的事實證明我的方法是正確的，驗收時PDM中60％的數據都是由他們兩人在日常工作中錄入的，最終對系統的肯定意見也是由他們最先提出的。我不想說明這個項目有多成功，我只想說明的是，當用戶有足夠的參與感時，這個項目基本上就已經成功了。這就好像自己養大的孩子，想不管他還真不是那么容易的。
剛才談到PDM項目的成功問題，應該來說是一個比較敏感但又不得不談的話題。在這里我想借用發哥在廣告中的話問問："成功是什么？"說的直接一點，就是如何評價一個PDM項目是否成功？或者說PDM項目的成功標準是什么？
很多人說PDM成功的標準是用戶。用戶天天在用，而且滿意，就說明這個項目成功了。在這里我想說的是：這不叫成功的標準，這最多只能算成功帶來的后果之一。要是按照用戶滿意度這個標準，這個世界上簡直就沒有成功的信息化項目。
不管你是否承認，每個人與生俱來就抗拒新生事務。比如上海人到了四川就吃不下飯，四川人到了廣東也沒辦法習慣當地的飲食。想想我們所謂的IT人自己，用慣了VC的人，你讓他改用其他的工具，還真不是那么容易的事情。己所不欲、勿施于人，當一個人被迫改變某種習慣，一定是受外力影響，不得已而為之，內心里是未必情愿的。所以我個人認為，依靠PDM的所謂價值去驅動用戶自己的主觀能動性基本是不可行的，因為PDM的那些所謂的價值什么的在實施當中根本起不到多大作用。
以前我們覺得，只要PDM真能給用戶提供價值，用戶就一定能夠自我激發從而促進項目的實施。我個人也在這種理論的影響下實施了2年，后來發現其實不是這樣的。就像我在前面說的，人自勵自發一定有外力驅動，這種外力要不就是壓力，要不就是動力。比如說一個軟件公司突然改變策略，要求用Java重新開發新的平臺，然后它要求所有的程序員必須學會Java，否則就走人。程序員們肯定惶惶不安，人人自危--這是壓力；但是公司換個方式，告訴所有的程序員，學會了Java，等這個新平臺開發出來給所有人加薪200％，程序員們肯定喜笑顏開，發奮圖強--這是動力。
但在PDM實施中我們面對的到底是壓力還是動力呢。以前我們希望用價值讓用戶產生動力，但是效果并不好。道理很簡單，設計人員的價值與企業上PDM的價值并不統一。設計人員希望的是快速提高自己的業務能力，希望以后的個人事業能夠有比較大的突破；而PDM的價值在于幫助企業實現TQCSE的和諧統一，雖然它也能對設計人員提高業務能力有所幫助，但是這些幫助非常有限，遠不如設計人員看書考研之類的來的直接。
動力這條路看來是不通了，只好試試壓力了。前面已經說了，設計人員尤其是老資格的設計人員多數都是企業大爺般的人物，領導都拿他們沒辦法，就更別提軟件公司了。那怎么辦呢？其實設計人員一般都受過良好的教育，受過良好教育的人一般都比較講道理，比較遵紀守法，企業里面設計人員很少有遲到早退的就是這個道理。所以要想給設計人員壓力最好的辦法就是制度！
有人說了，你這也是廢話，上信息化的都知道要在制度上予以保障。但是我這里說的制度還與企業那種上綱上線的制度不太一樣，那種制度很死板，而且真要立那樣的制度還要經過層層審批，并不是件容易的事情。我這里說的制度是找一個點，只要在這個點上進行嚴格把關，就能給設計人員形成很大的壓力。我在另外一個企業實施的時候發現，工藝部門接收設計部門的圖紙時都需要經過工藝簽審這一關，而負責工藝簽審的人工作又不是特別的繁忙，于是我就重點培訓了他，并讓技術部門領導口頭下令，所有交給工藝簽審的圖紙必須進入PDM系統，否則工藝部門可以予以拒絕。OK，這招非常管用，短短6個月，PDM中就已經有了各類零部件圖紙8000余張。
那有了制度，企業設計人員也用起來了，PDM中也有數據了，能不能說這個PDM項目成功了呢？別高興太早，還不行！
剛才談到成功標準的問題，其實就是一個PDM項目的項目目標問題，就算用起來了，沒有達到項目目標，我們一樣說這個項目沒有成功，但是反過來，達到了項目目標，沒有真正用起來，卻可以說這個項目是成功的。
有人說，你這個觀點好奇怪，沒用起來怎么可能達到目標呢。但是在我們國家這種體制下就是可能的。比如有些PDM項目是科研性質的，要求的是系統的先進性，雖然也重視實用性，但是先進性是主導的。這種事情在很多高校承接的PDM課題項目中并不鮮見。就好像很多電子產品，在市場上是失敗的，但是在技術上是成功的。這實際上是一個組織目標與業務目標的命題。組織目標與業務目標一致，這個項目往往比較容易得到應用，但是如果組織目標與業務目標本來就不匹配，那么往往只能犧牲業務目標而達到組織目標。
所以，在實施PDM的時候，首先需要明確定義的就是項目實施目標。個人覺得現在是回歸理性的時候了，企業也好，軟件公司也好，應該摒棄所謂的項目管理、協同設計之類的花哨名詞，轉向更加實際的，可以量化的項目實施目標，比如要求在什么時間內滿足什么需求，在什么時間內，達到多少數據量等等。
看過國內某知名Smarteam代理公布的數據，Smarteam70％的用戶只做了圖文檔管理；一個參與Teamcenter在FORD實施的朋友介紹，Teamcenter在FORD實施了三年，也只做了圖文檔管理。那個朋友還告訴我，Teamcenter一些花哨的功能FORD一概不要，它要的就是實用和穩定。由此看來，比起國內企業動不動就要PDM實現項目管理、協同設計之類的功能來，老外還是比國內的企業務實一點。
項目目標一旦確定，所有的實施活動都按照這個目標進行倒排就行了，項目的時間進度、人力資源的分配等等項目要素都可以隨之展開。PDM的項目管理我這里就不展開了，否則就可以寫一本書了。我這里要說的是PDM項目實施過程中最容易被人提起也最容易被人忽視的內容--項目溝通。
看過部分外國PDM系統的實施方案，發現每周一個項目例會是寫在方案里面的。以前以為只是做秀，后來一了解，還真就是那樣，而且老外組織開項目例會不流于形式，非常坦誠，行就是行，不行就是不行。就拿提BUG或者需求這事情來說，Teamcenter將BUG或者需求分四級，0級是解決不了系統就不能正常運行的，比如不兼容某個操作系統之類的；1級是不解決無法開展業務的；2級是可以采用其他辦法解決但比較麻煩需要優化的；3級是目前已經能夠解決但是有更好解決方案的。用戶在向Teamcenter提出BUG或者需求的時候，是雙方項目組通過充分的溝通產生的按級別區分的報告。但是在國內，除了軟件公司內部的BUG庫，很少有那個軟件公司能如此細致的區分用戶提出的BUG或者需求。無法區分一方面是缺乏對用戶業務的足夠了解，另外一方面就是沒有保持足夠的溝通。
在PDM實施過程中，客戶提BUG或者需求簡直如家常便飯，而且應用越深入提的越多。但是用戶缺乏對軟件的足夠了解，要么覺得這個問題軟件公司改起來非常容易，要么就把一個不怎么重要的BUG或者需求上升到不解決就不驗收的地步。用戶不了解情況不是他的錯，但是實施人員不去主動判斷，不去主動溝通就不對了。
我在實施過程中，開發人員經常拿著一疊BUG/需求報告跑來問我："哪些是緊急的必須要改的，你挑出來我優先解決。"我對他說："我提這些主要是想幫助公司的軟件進步，事實是不需要任何的開發我也能夠讓用戶將這個系統用起來，因為我們的PDM已經比較成熟，基本功能是夠用的。"我說這些并不是說我有多牛，我是想說在一個已經相對比較成熟的已經得到過大量用戶驗證過的PDM系統面前，一些基本的功能是穩定且實用的，在向開發人員提出BUG或者需求之前，應該多想想如何通過溝通打動用戶讓他把這些基本功能先用起來。
溝通還有一個重要作用就是增進雙方感情，減小實施阻力。當然這也是廢話，因為所有的PDM實施項目都非常重視實施人員的溝通能力，企業在挑選自己的項目組成員的時也會選那些溝通能力比較好的。不過不管承認不承認，雙方的項目組成員在溝通時都有意無意的保持距離，似乎大家都抱著不可告人的秘密。
企業里面的秘密我不知道，但是軟件公司的秘密我還是有所了解的。軟件公司無非就時怕實施人員出去亂說話，比如垂頭喪氣的表示對軟件的無奈或者亂向用戶做出承諾等等。以我的看法，亂說都比不說要強。呵呵，又是一個語出驚人是不是。
現在人都不是傻瓜，現在PDM軟件廠商的銷售經理都深感用戶原來越理性，所以現在瞞天過海的伎倆已經不實用了，所以在我面對用戶的時候，盡量保持坦誠。除非是公司的核心商業機密，否則個人認為沒有什么不能說的，唯一的問題是說的時機。這就像打牌，你手上的牌早晚都是要出的，只是看先出還說后出。我曾經當著用戶的面跟我們的開發測試人員打電話發表強烈不滿，曾經愁眉苦臉的跟用戶高層述說實施過程的艱辛，曾經大聲向用戶宣布我們打下的新單……當然，這存在一個時機問題，至于時機的把握，那就看實施人員的能力了。
剛才談了一下溝通的態度，現在談談溝通的方式，個人認為這也是實施過程中非常重要的一環。其實溝通的方式無外乎就是電話溝通、郵件溝通、當面溝通和書面溝通幾種。但是很多PDM實施項目小組的成員往往忽略了對溝通進行記錄，這個是非常要命的。我在實施過程中，每天都寫工作記錄，每周形成工作備忘錄交給用戶，通過溝通了解形成的需求或者BUG也一定形成文檔。每次項目例會一定有專人負責記錄，會后保證參與人員人手一份會議記錄。最后這些記錄文檔在驗收過程中形成了巨大作用，我用詳盡的數據和記錄向用戶證明，我們做到了什么，有那些沒做到，為什么沒做到，項目發生延期的原因。看到這些記錄，用戶高層幾乎沒有考慮就在驗收報告上簽了字。
關于實施的話題其實很長，從實施方法的角度而言，國內國外PDM軟件的雖然細節有很多不同，但是方法基本都是一樣。我個人認為也沒必要非要爭出個孰優孰劣，時間自然會證明一切。關鍵是怎么看待PDM的實施問題，我覺得只要肯投入（未必是金錢方面的，但是金錢也是必不可少的），本著共同實施，共同承擔風險的態度，多溝通，多讓用戶參與，PDM的項目就一定能實施成功。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：如何進行PDM系統的實施？
本文網址：http://www.guhuozai8.cn/html/consultation/1082063605.html
相關文章
