PLM已經是一個廣為接受的概念。從字面意思可以看出，PLM系統的核心任務是進行“產品生命周期管理”。在PLM系統中，零部件也有生命周期，反映零部件的階段和狀態。而企業實施PLM系統過程中的一個主要任務，就是定義零部件的生命周期構成及演進規則。

二、過短的零部件生命周期

PLM系統對于零部件的“生命周期”管理應用，很容易被實施得過于簡單，其“生命周期”過程往往是指零部件的“設計周期”管理過程，零部件的發放實際指的是“設計完成”，而非投入生產。

圖1 過短的生命周期過程管理

如上圖是某公司PLM系統中定義的零部件生命周期過程管理圖。當零部件創建出來時即處于“擬制”狀態，這時研發工程師對零部件進行各方面的詳細設計。設計完成之后，研發工程師將啟動一個審批流程，提交流程后，審批流程進入到“審核”環節，零部件的生命周期狀態處于“流程中”；如果審核人員發現設計有誤，則駁回給研發工程師，研發工程師根據審核意見進行修改，然后再提交，如此往復。

如果審核通過，則將進入到“批準”環節，“批準”環節的簽審過程與“審核”一樣，只是簽審人員不同。如果批準通過，則將進入放到“發放”環節，此時，零部件的生命周期提升到“歸檔”，零部件被凍結；批準后的“發放”環節主要是將零部件圖紙及技術資料發放給生產制造部門，過程提交通過之后，審批流程完成。

上述整個過程都發生在研發部門內部，工藝和制造部門則不參與。當零部件被發布后，工藝和制造部門才在此基礎上展開工作。如果工藝或制造部門在后面發現了問題，他們會通知研發部門，于是研發工程師將零部件修訂一個新版本（申請變更或申請取消歸檔），然后根據下游或現場反饋的情況在新版本上進行修改，修改完成后再次進行上述的審批流程，然后發放一個新版本，完成變更。

按照這個模式，零部件的一個生命周期實際上指的是零部件在研發部門的一段生命期，如果零部件通過了研發部門的審核，即代表生命周期走到了終點。當下游部門提出零部件有缺陷時，零部件需要“重生”一次（修訂一個新版本），然后經歷一個新的生命周期。我們來看一下一個零部件的一般開發過程。一個零部件從概念階段到批量生產，一般要經歷如下階段：

圖2 零部件設計開發基本過程

可以看出，零部件設計階段只占全部生命周期的一半，后面還有大量的驗證工作需要進行。而研究表明，產品80%的修改是在制造階段以后完成的。從這個角度看，設計階段的完成實際連整個生命期的一半都不到。這個時候宣布零部件“發布”實際上不合適，就如同一個大學生剛完成本科學業就宣布他已經成才一樣。

這種情況的發生并非偶然�，F在很多制造企業的組織結構仍然是行政式的，研發部門負責產品研發，制造部門負責試制生產；工作流程也一般是串行的，研發部門將設計簽審后的圖紙交到下游部門試制生產，出現問題再向上游反饋，而在零部件設計階段他們參與得很少。

而PLM系統的實施則往往從研發部門開始，然后再延伸到制造部門，有的甚至只局限在研發部門內部。這樣在系統部署之初，對零部件的生命周期的定義就只定義到設計階段，而一般不會從整個過程的角度去定義。同時，一些企業“甩過墻”式的設計習慣也加強了這種情況。所謂“甩過墻”的設計是指“我這個部門完成我的工作后就把結果甩給隔壁的部門，然后沒我的事情了”。

三、零部件生命周期過短的影響

無論這種情況是如何產生的，帶來的影響卻是相同的——零部件實際上沒有完整的生命周期。零部件在設計階段被“歸檔”后，下游部門提交的變更只能在新版本上進行，這就扭曲了版本本身的作用。

在PLM系統中，版本信息一般由版本和版次構成。版次標記一次修改，版本標記一次發放。這里的發放是指零部件已經“歸檔”，即：完成設計驗證并投入生產。從標記修改的角度看，版本可理解為：版次標記投入生產之前的修改，版本標記投入生產之后的修改。由于生產前的驗證和準備投入了大量的時間和成本，因此對零部件在生產之前和生產之后的變更處理是不同的。

在零部件投入生產之前，模具尚未開模，采購訂單尚未下發，大量成本尚未發生。這時零部件處于設計或驗證階段，目標之一就是盡可能地發現和消除零部件的缺陷，使零部件具備高質量，因此這時發生的修改應該是即時生效的。

而零部件一旦投入生產，則大量成本已經發生，對修改的處理變得謹慎。并且投入生產的零部件一般是經過驗證的，這時發現的問題往往是改進性質的，因此修改一般不會即時生效，而是有可能等到下一款產品才實現，或等現有供貨耗完后才使用新設計。當然，也不排除一些致命缺陷需要及時修復，而這在投入生產后一般要少得多。因此，二者處理的主要問題一個是糾錯型，一個是改進型。直接的不同就是修改是否要即時生效。

在一般的PLM系統中，零部件在未歸檔之前的修改只增加版次，并且新的版次會即時生效，即部件會馬上自動引用新版次，而版本的增加一般不會即時生效。一般是當部件未歸檔時，新版本的零件歸檔后部件會自動引用新版本零件。當然，如果部件也已歸檔時，則新版本的零件歸檔后部件不會自動引用新版本零件，如果要引用，則需要將部件修訂一個版本，然后再一起歸檔。這與產品投放生產后的改進是一致的。不過，當零部件的生命周期僅代表其設計周期時，就打破了上面的規則。

試想，當某一部件設計完成，研發部門將其一起“歸檔”。而后下游部門發現部件或零件存在問題，并提交給研發部門修改。這時研發工程師需要將部件修訂一個新版本然后進行修改，這意味著之前“發放”的版本實際并未進行生產，這就扭曲了“發放”的本意。

不僅如此，若需要修改的是部件下的零件（實際上大部分情況都是修改零件），那么新版本的零件發放后該部件不會自動引用新版本，這樣就必須修訂該部件。如果部件有父級，則需要依次往上修訂，這樣一次修改就會產生大量的修訂，勢必使變更效率變慢。如果不想層層往上修訂，則必須把系統開發成“即使父項處于發放狀態，子項修訂新版本后，父項也會自動引用新版本子項”。這樣做產生的問題是：部件永遠處在新狀態下，這樣失去了對歷史狀態的追溯功能。

因此，無論從那個角度考慮，一旦零部件走出了設計階段，這個生命周期過程圖就無法再準確描述其生命周期階段和狀態。

四、零部件生命周期管理的一般性建議

上述問題的產生，是由于零部件的生命周期圖只描述到設計階段完成，而零部件后面的演進則超出了這個階段，即：用較短的生命周期圖描述較長的生命期。要解決這個問題，需要將產品的生命周期管理延伸到設計驗證和制造階段。產品設計階段的完成只能定義為“設計凍結”，而不能定為“發放”。真正的“發放”定義在產品驗證完成后，批量生產之前。如下圖：

圖3 零部件長生命周期過程管理

上圖中，在“設計凍結”之前，零部件處于設計階段，研發工程師可以對零部件進行修改，所有的修改完成后，便可提交審核，并進入“設計凍結”環節。零部件審批流程進入到“設計凍結”環節，在此該階段，研發工程師無權再進行修改。

    “設計凍結”環節表示零部件設計階段的完成，但尚未“歸檔”。當下游部門發現問題時，便提交給研發部門。研發工程師接到修改意見后，可將回退流程到“創建”環節進行修改，修改完成后零部件增加一個版次，其父級也自動引用新版次子項。提交審批流程經簽審人員批準通過后，零部件審批流程再次進入到“設計凍結”環節。所有對反饋問題的處理都遵循這個模式。當驗證階段反饋的所有問題都被妥善處理并經過項目組評審通過后，產品數據（包含零部件及關聯圖紙）便可以提交“歸檔”。

一旦產品數據進入“歸檔”階段，系統便將其凍結，作為歷史查詢記錄。用戶若要修改，則需要將提交變更審批流程，將其修訂新的版本，然后在新的版本上進行修改操作。

對于一些特殊情況，即在生產階段發現的一些嚴重缺陷因而不得不進行的修改。這時需要提出變更申請（ECR）審批流程，經由相關部門會簽通過后方可進行修改與下發（ECN）。這種情況必須嚴格控制，因為生產之后的修改必然伴隨這高昂的成本。

表面上看，圖3相比與圖1中的生命周期管理過程只增加了兩個生命周期階段，但實際上卻有很大的不同。在圖1的生命周期中，設計完成即表示產品“歸檔”，產品驗證和批量生產前的階段被排除在零部件生命周期之外；而這個長生命周期過程圖則將產品設計完成后批量生產前的階段也囊括到產品生命周期內，產品只有等全部數據驗證通過后才能夠“歸檔”并“發布”。

現在，咨詢機構和廠商更愿意把PLM管理的生命周期延伸到銷售、生產和售后階段，從這個角度看，要實現零部件的全生命周期管理依然任重道遠！這里面不僅僅只是增加若干個生命周期階段的問題，而是這些階段之間是如何演進及需要遵循哪些基本規則。

來源：網絡  侵權刪