PLM已經是一個廣為接受的概念。從字面意思可以看出，PLM系統最核心的任務是進行“產品生命周期的管理”。在PLM系統中，零部件也有生命周期，反映零部件的階段和狀態。而企業實施PLM系統過程中的一個主要任務，就是定義零部件的生命周期構成及演進規則。
過短的零部件生命周期管理
我曾參與過一些公司PLM系統實施，發現方案中零部件所謂的“生命周期”往往是指零部件的“設計周期”；零部件的發放實際指的是“設計完成”，而非投入生產。
圖1 過短的生命周期圖
如上圖是某公司PLM系統中定義的零部件生命周期圖。當零件創建出來時即處于“創建”階段，這時工程師對零件進行各方面的詳細設計。一旦完成，工程師將零件的生命周期狀態提升到“審核”，這時啟動一個審核流程； 如果審核者發現設計有誤，則駁回給工程師，工程師根據審核意見進行修改，然后再提交，如此往復。如果審核通過，則零件生命周期狀態提升到“批準”階段，同時觸發一個批準流程。批準流程的簽審過程與“審核”一樣，只是簽審人不同。如果批準通過，則零件生命周期提升到“發放”，零件被凍結。若需要修改，則需要將零件修訂一個新版本，然后在新版本上進行修改。
上述整個過程都發生在研究部門內部，工藝和制造部門則不參與。當零件被發放后，工藝和制造部門才在此基礎上展開工作。如果工藝或制造部門在后面發現了問題，他們會通知研發部門，于是工程師將零件修訂一個新版本，然后根據下游或現場反饋的情況在新版本上進行修改，修改完成后再次進行上述的簽審流程，然后發放一個新版本，完成變更。
按照這個模式，零件的一個生命周期實際上指零件在研發部門的一段生命期，如果零件通過了研發部門的審核，即代表生命周期走到了最終點。當下游部門提出零件有缺陷時，零件需要“重生”一次（修訂一個新版本），然后經歷一個新的生命周期。
我們來看一下一個零件的一般開發過程。一個零件從概念階段到批量生產，一般要經歷如下階段：
圖2 零部件的開發過程
可以看出，零件設計階段只占全部生命期的一半，后面還有大量的驗證工作需要進行。而研究表明，產品80%的修改是在制造階段以后完成的。從這個角度看，設計階段的完成實際連整個生命期的一半都不到。這個時候宣布零件“發放”實際上不合適。就如同一個大學生剛完成本科學業就宣布他已經成才一樣。
這種情況的發生并非偶然。現在很多制造企業的組織結構仍然是行政式的，研發部門負責產品研發，制造部門負責試制生產。 工作流程也一般是串行的。研發部門將設計簽審后的圖紙交到下游部門試制生產，出現問題再向上游反饋，而在零件設計階段他們參與得很少。而PLM系統的實施則往往從研發部門開始，然后再延伸到制造部門。有的甚至只局限在研發部門內部。這樣在系統部署之初，對零件的生命周期的定義就只定義到設計階段，而一般不會從整個過程的角度去定義。同時，一些企業“甩過墻”式的設計習慣也加強了這種情況。所謂“甩過墻”的設計是指“我這個部門完成我的工作后就把結果甩給隔壁的部門，然后沒我的事情了”。
零部件生命周期過短的影響
無論這種情況是如何產生的，帶來的影響卻是相同的——零件實際上沒有完整的生命周期。零件在設計階段被"發放"后， 下游部門提交的變更只能在新版本上進行，這就扭曲了版本本身的作用。
在PLM系統中，版本(revision)一般由大版本(version)和小版本(iteration)構成。小版本標記一次修改，大版本標記一次發放。這里的發放是指零件已經完成設計驗證并投入生產。從標記修改的角度看，版本可理解為：小版本標記投入生產之前的修改，大版本標記投入生產之后的修改。由于生產前的驗證和準備投入了大量的時間和成本，因此對零件在生產之前和生產之后的變更處理是不同的。
在零件投入生產之前，模具尚未開模，采購訂單尚未下發，大量成本尚未發生。這時零產品處于設計或驗證階段，目標之一就是盡可能地發現和消除零件的缺陷，使零件具備高質量。因此這時發生的修改應該是即時生效的。
而零件一旦投入生產，則大量成本已經發生，對修改的處理變的謹慎。 并且投入生產的零件一般是經過驗證的，這時發現的問題往往是改進性質的。因此修改一般不會即時生效，而是有可能等到下一款產品才實現，或等現有供貨耗完后才使用新設計---當然，也不排除一些致命缺陷需要及時修復，而這在生產后一般要少得多。
因此，二者處理的主要問題一個是糾錯型，一個是改進型。最直接的不同就是修改是否要即時生效。
在一般的PLM系統中，零件在未發放之前的修改只增加小版本，并且新的小版本會即時生效，即父級會馬上自動引用最新小版本；而大版本的增加一般不會即時生效。一般是當父級未被發放時，新版本的子級發放后父級會自動引用新版本：如果父級已發放，則新版本的子級發放后父級不會自動引用新版本。如果要引用，則需要將父級修訂一個版本，然后再發放新版本的子級。 這與產品投諸生產后的改進是一致的。如下圖：
圖3 零部件版本管理
但當零部件的生命周期僅代表其設計周期時， 就打破了上面的規則。
試想，當某一部件設計完成， 研發部門將其及子項悉數“發放”。而后下游部門發現部件或子項存在問題，并提交給研發部門修改。這時工程師需要將部件修訂一個新版本然后進行修改。這意味著之前 “發放”的版本實際并未進行生產，這就扭曲了“發放”的本意。
不僅如此，若需要修改的是部件的子項（實際上大部分情況都是修改子項），那么新版本的子項發放后該部件不會自動引用新版本。這樣就必須修訂該部件。如果部件有父級，則需要依次往上修訂。這樣一次修改就會產生大量的修訂，勢必使變更效率變慢。如果不想層層往上修訂，則必須把系統開發成“即使父級處于發放狀態，子項修訂新版本后，父項也會自動引用新版本子項”。這樣做產生的問題是：部件永遠處在最新狀態下，這樣失去了對歷史狀態的追溯功能。
因此，無論從那個角度考慮，一旦零部件走出了設計階段，這個生命周期圖就無法在準確描述其生命階段和狀態。
建議
上述問題的產生，是由于零部件的生命周期圖只描述到設計階段完成，而零部件后面的演進則超出了這個階段。即用較短的生命周期圖描述較長的生命期。要解決這個問題，需要將產品的生命期延伸到驗證和制造階段。產品設計階段的完成只能定義為“設計凍結”，而不能定為“發放”。真正的“發放”定義在產品驗證完成后，批量生產之前。如下圖：
圖4 零部件生命周期管理
上圖中，在“設計凍結”之前，零部件處于設計階段，研發部門工程師可以對零部件進行修改；所有的修改完成后，便可提交審核，并最終進入“設計凍結”。零部件提升到"設計凍結"需要做一個校驗:只有當所有子項被提升到"設計凍結"后，父項才能提升到"設計凍結"。 在該階段，研發部門部門工程師無權再進行修改。
“設計凍結”表示零部件設計階段的完成，但尚未“發放”。當下游部門發現問題時，便提交給研發部門。研發部門工程師接到修改意見后，可將零部件降級到"創建"狀態進行修改。修改完成后零部件增加一個小版本，其父級也自動引用新的小版本。然后零件被提交簽審，簽審通過后，零件再次提升到“設計凍結”，系統收回工程師的修改權限。 所有對反饋問題的處理都遵循這個模式。當驗證階段反饋的所有問題都被妥善處理后，產品便可以提交發放。同“設計凍結”一樣， 產品發放時也要遵循一個原則：只有當所有的子項發布后， 父項才能被發布。
一旦產品進入“發放”階段，系統便將其凍結，作為歷史查詢記錄。用戶若要修改，則需要將其修訂新的大版本，然后在新的版本上進行修改操作。 當然，新的版本發放后，其父級不會自動引用。
對于一些特殊情況，即在生產階段發現的一些嚴重缺陷因而不得不進行的修改。這時需要提出修改申請，然后由具有管理員權限的賬戶執行對發布后的修改。 這種情況必須嚴格控制。因為生產之后的修改必然伴隨這高昂的成本。
表面上看，圖4與圖1中的生命周期只增加了兩個生命周期階段，但實際上卻有很大的不同。在圖1的生命周期中，設計完成即表示產品“發放”，產品驗證和批量生產前的階段被排除在零部件生命周期之外；而這個生命周期圖則將產品設計完成后，批量生產前的階段也囊括到產品生命周期內，產品只有等全部驗證通過后才被認為能夠“發放”，因此是將設計和工藝制造視為一個流程內。
現在，咨詢機構和廠商更愿意把PLM管理的生命周期延伸到銷售和售后階段，從這個角度看，要實現零部件的全生命周期管理任重而道遠！這里面不僅僅只是增加若干個生命周期階段的問題，而是這些階段之間是如何演進及需要遵循哪些基本規則。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：談零部件的生命周期管理
相關文章
