要實現(xiàn)ERP和PDM系統(tǒng)集成

摘要：這就需要和客戶確認關鍵流程之一“明細表審批流程”，一般是通過(研發(fā)設計工程師)提出－(主管工程師)審核－(標準化)審核－(工藝人員)會簽－(BOM)審批－歸檔。3.3. PDM\ERP究竟集成哪些屬性 　　流程只是搭建更改的通道，下面將是確定這個自動通道上的流轉(zhuǎn)貨物，確定哪些屬性是ERP和PDM的共有屬性，需要做同步更改。

在PDM系統(tǒng)中，有很重要的一個模塊就是“產(chǎn)品配置”模塊－“對產(chǎn)品的零部件或者組件以抽象的計算機能識別的方式表述出來”

　　1. 背景描述

　　在PDM系統(tǒng)中，有很重要的一個模塊就是“產(chǎn)品配置”模塊－“對產(chǎn)品的零部件或者組件以抽象的計算機能識別的方式表述出來”，通常包括零部件的“名稱、代號、規(guī)格、材質(zhì)”等信息，國產(chǎn)PDM和國外的PDM可能叫法上有細微的差異，在PDM系統(tǒng)中以層次結(jié)構(gòu)關系表現(xiàn)出來，稱之為“明細表”，對于研發(fā)來說，關注的是產(chǎn)品裝配關系表現(xiàn)的“設計BOM”；對于工藝生產(chǎn)部門來說，關注的是體現(xiàn)原材料、工藝定額的“制造BOM”，或稱為“ERP　BOM”　當然還有“計劃BOM”等，我們重點分析下研發(fā)設計部門產(chǎn)生圖紙后編制明細如何將研發(fā)明細轉(zhuǎn)換為“ERP　BOM”，以及PDM系統(tǒng)研發(fā)明細更改后如何自動、精準地傳給這些改動給ERP系統(tǒng)的“ERP BOM”，使之做同步更改，這也是多數(shù)企業(yè)更改明細或者圖紙不能同步更改碰到一個難題。

　　2. 達到目標

　　當研發(fā)設計明細更改時候，同步更改PDM系統(tǒng)的設計BOM和ERP的BOM,目的是從源頭上保證設計更改單更改信息完整、精準自動傳遞。

　　3. 需求調(diào)研

　　要想實現(xiàn)ERP和PDM系統(tǒng)集成，達到研發(fā)設計更改同步會影響ERP系統(tǒng)BOM,滿足業(yè)務需要，較初的調(diào)研是非常有必要和重要的一步。

　　3.1. 調(diào)研人員的選擇

　　通常來說，對PDM系統(tǒng)來說，調(diào)研對象：標準化管理員，具備“物料管理員”角色，對ERP系統(tǒng)來說，毫無疑問應該是ERP的BOM管理員。同時調(diào)研較好甲方的人員參與，一來便于后期的維護，再就是得到相關人員的配合。

　　3.2. 兩個關鍵流程的確定

　　明細表審批流程

　　既然是想做到研發(fā)的明細能自動集成，寫入到ERP系統(tǒng)，而不是再經(jīng)過ERP BOM員的手工錄入，以減少BOM出錯的機會。這就需要和客戶確認關鍵流程之一“明細表審批流程”，一般是通過(研發(fā)設計工程師)提出－(主管工程師)審核－(標準化)審核－(工藝人員)會簽－(BOM)審批－歸檔。當然可根據(jù)每個企業(yè)的實際業(yè)務情況做調(diào)整。

　　設計更改流程

　　各個企業(yè)提出變更的源頭不一，有些是“降成本”的要求，有些是研發(fā)的“結(jié)構(gòu)改進”等，還有些是客戶投訴，提出變更等。有些變更比較緊急，可能直接影響生產(chǎn)等，這就需要“特事特辦”；有些是屬于普通變更則嚴謹?shù)刈咄暾麄€流程。

　　需要重點說明的是：這兩個流程很重要，較好在會上邀請相關人員進行討論，討論簽字確認。

　　3.3. PDM\ERP究竟集成哪些屬性

　　流程只是搭建更改的通道，下面將是確定這個自動通道上的流轉(zhuǎn)貨物，確定哪些屬性是ERP和PDM的共有屬性，需要做同步更改。

　　物料屬性

　　物料屬性是零部件本身屬性，例如：圖號、名稱、規(guī)格、材質(zhì)等屬性，這個時候需要特別注意ERP 的item描述規(guī)則，一般來說ERP的描述會自動由這些屬性合成的，找到這些共性規(guī)則。

　　明細屬性

　　明細表屬性簡單描述就是整個產(chǎn)品的結(jié)構(gòu)層次關系，例如可能增加、刪除某層下的物料或者更改它的數(shù)量，這些是較基本的。當然可能企業(yè)的ERP系統(tǒng)根據(jù)客戶的需要做了些開發(fā)，例如：電子類產(chǎn)品可能加上位置號等。這個時候需要考慮是否PDM明細表里面加上對應的字段以便做變更。同時還要考慮項目整個進度。形成需求調(diào)研后要簽字確認，防止后面的無限制需求提出。

　　另外需要提醒的是：若是設計BOM和制造BOM若有結(jié)構(gòu)差異，那就需要確定兩邊BOM不一致，可以向那邊靠攏；若是無法向一邊靠攏，則要找出設計BOM向ERP BOM的轉(zhuǎn)換規(guī)律，若是兩張方法都不行，則無法做到系統(tǒng)自動變更。

　　4. 設計開發(fā)

　　現(xiàn)在要做的是把業(yè)務的實際需要轉(zhuǎn)換為程序設計，這個時候較好將前期調(diào)研的資料做的很細致，包括集成的字段在ERP對應界面上的截圖，防止后面的扯皮現(xiàn)象。

　　較怕碰見系統(tǒng)不支持的屬性，或者是需要做很多開發(fā)工作才能解決，這個時候?qū)嵤┤藛T就要想辦法，可以“曲線救國”找個替代方案。只要不是關節(jié)點，都可以從大局角度說服客戶。

　　5. UAT業(yè)務測試

　　一旦程序設計開發(fā)好后，較好就是測試：功能測試、UAT用戶測試

　　這個時候千萬不要以為自己做個功能測試，走完變更單后沒有什么bug就萬事大吉了，較主要的是自己測試發(fā)現(xiàn)沒什么問題后，編制個測試大綱，發(fā)放相關業(yè)務部門人員，然后把這些人召集在一起，不同角色的人員都要有，從源頭開始測試，一直測試走完到ERP,再讓ERP的BOM員和管理員確認是否有問題？若是沒問題，簽字。個人覺得簽字還是很有必要，要簽字客戶才會重視起來，后面若是有什么問題影響到生產(chǎn)數(shù)據(jù)，至少不會全是供應商的責任吧？

　　測試通過，然后就是很領導匯報下測試結(jié)果，后面就是用戶培訓了，較后就是讓用戶體驗自動更改的便利吧。